Serendipity Forums

I've uploaded a diff -u patch against that latest nightly tarball to fix an implicit casting error when using PostgreSQL 8.3 and above.

The patch file is at http://www.openvistas.net/functions_config.patch

Thanks,

Jeff Ross

Hi!

I believe that patch would need to be checked first if $serendipity['dbType'] equals a pgsql layer, because this kind of casting might notwork on pgsql and mysql...?!

Since you seem to be using one of the pgsql versions where implicit casting was sadly removed, do you find other placers as well? s9y relied on a lot of implicit type casts in several areas and plugins...

Many thanks for your input!

Regards,
Garvin

I've only just got serendipity up and running, and the user that requested it hasn't made her first post yet.

As queries fail, I'll fix them and send patches.

As far as the cast( expr as type ) syntax goes, this is the SQL standard, and is supported by MySQL as far back as 3.23, as this entry in the on-line manual shows:

http://dev.mysql.com/doc/refman/4.1/en/ ... on_convert

I can't vouch for sqlite as I've never used it, but in another post griffinn stated that cast( expr as type ) is also valid for sqllite.

http://board.s9y.org/viewtopic.php?t=12 ... sc&start=0

and the sqlite docs he references are here:

http://www.sqlite.org/lang_expr.html

However, if you want to wrap the code to with logic to include only PostgreSQL I'm fine with that.

I uploaded a new patch file to

http://www.openvistas.net/functions_config.patch

Thanks,
Jeff Ross

Hi!

Wow. Awesome. I didn't know you checked on all of that - I should've better done that.I never saw such SQL in MySQL, but I'm glad you prove me wrong. In that case I'll use your patch on my dev build and can then committ it!

Best regards,
Garvin

Excellent!

So, would you like me to continue with the logic wrapper style? Believe me, implicit casts really are evil, and a little googleing will show you why. I don't think it would hurt the code base at all to fix all the implicit casts once and for all.

Jeff

Hi!

Yes, continuing like that where applicable would be good. However, there are places in the code where the input can be a string OR a number. s9y offers an abstract "name, value" association in the serendipity_config DBtable.

Some plugins store numbers, some store strings in those fields. In some cases, SQL lookups uses ">" or "<" comparison logic, while in others a "=" comparison is used, and for the lookup we cannot safely use a cast because the field values might differ.

I don'T remember the exact places of stuff like this, and there's also this:

http://board.s9y.org/viewtopic.php?t=12 ... licit+cast

The column name can be altered by plugins, and the column value also. So some plugin might set the column from "id" to "title", and the value matchup might be changedfrom "82" to "string", and where the SQL query is joined, the code does not really know what thefinal outcomewill be.

A general "LIKE" was used currently, because it fitted in all SQL engines,until PGSQL changed their view and enforced a hard compatibility
break. The only way I see to change this is to make one giant introspection function that checks each column type before it is queried, which of course puts performance pressure on the DB.Or the checks would need to be hardcodded, but then it would not be so flexible to a plugin API approach and all new possible columns would needed to be addedto the white/blacklist.

So I'd really like to still appreciate implicit casts. The sql engine should imho do that for me as a convenience function, especially if such beaviour existed in past versions and is used in alot of code.

Regards,
Garvin

Jeff - welcome to the serendipity DEVELOPER community!!!! You can never leave!!! Seriously, appreciate your efforts and look forward to the other contributions I am sure you will make!