[Koha-devel] Adding support for PostgreSQL, no new MySQLisms, please

Marc Balmer marc at msys.ch
Sat Mar 24 16:05:17 CET 2012


Am 24.03.12 15:35, schrieb Robin Sheat:
> Op 25-03-12 03:19, Marc Balmer schreef:
>> No, it does not rewrite any reports.  If users enter SQL somewhere, I
>> assume they enter proper SQL for their DB server.  Which leads to a
> 
> OK, so it doesn't address this (quite minor) problem.

It would mean parsing the SQL and rewriting it.  I think - besides that
is hard to do right - it would be way over the top.

> 
>> I am considering to write a set of compatability functions for
>> PostgreSQL that add the most used MySQL functions, but I don't know yet
>> how to mimick server crashes and data loss that can occur in MySQL :>
> 
> I'd have a look through the reports library on the wiki and see what
> functions are in use. There won't be many. ExtractValue is the only
> common one I know of, dunno if the pgsql equivalent is syntactically the
> same.
> 
>> Id'd say it becomes clear once look at the bug and code.  DBQ stands for
> 
> The bug doesn't count once the code is in master. The code isn't clear
> because the documentation doesn't say anything about what it does, so
> there's no context. So no, not clear at all for someone trying to figure
> out what a particular call's purpose is.
> 
> One particular example:
> 
> =head2 ifNull
> 
> $value = $dbq->ifNull($a, $b);
> 
> Returns $a if not null, else return $b
> 
> =cut
> 
> This is actually wrong if you take it at face value out of context. It
> returns a string that does that in the database. That should be noted.
> But more importantly, there's no documentation saying anything about the
> purpose of all this. Don't assume people can work it out from the code
> because that's a waste of their time. Make it explicit. You're creating
> an API that can be produced by perldoc. (This said, it's nice to see
> perldoc comments in there at all - so much of the code doesn't have
> anything.)
> 
> As an aside, the lack of placeholder use in these functions is a little
> scary. I know that's hard to do, but it'd be worth trying.
> 
>> Data Base Query and ir produces database specific SQL.  It must only be
>> used where there is no other way to get the job done (i.e. don't use it
>> to produce DB specific code when there is a standard SQL way of doing so
>> or when there is corresponding functionality in DBI).
> 
> Then say this somewhere in the documentation.

FWIW, there is some explanations on the wiki at
wiki.koha-community.org/wiki/PostgreSQL.

It is work in progress, so see it in that context.  In the end, it will
be documented, it's just that we don't know yet which idioms exactly
need to go into DBQ (it will become more clear once we can install Koha
on PostgreSQL and are able to actually test the real functionality).

- mb



More information about the Koha-devel mailing list