last update_n doesn't work in postgres

Shiny,

Cool! Thank you for the patches. Ran in the same problem here.

Alexis

Ehehehe, I was thinking of filing this bug report. Surprised to see that PG users are increasing.
And of course with patches.

There is the same problem in the print_mail module for those who use it. See attached.

Thank you.
Alexis

Hi,

Thanks for the patch (next time remember print_mail :P)!

I try to create and test pg compatible SQL, but I have to say that I usually test only the runtime code of the module in the alternate platform. My bad.

I've committed it to CVS.

João

There's just one error you made everywhere repeatedly.
Let's say, a & b are integer & character respectively.

SELECT a, b where a = 0 and b = 0; - this works in mysql but not in pgsql
SELECT a, b where a = 0 and b = "0"; - this works in mysql but not in pgsql
SELECT a, b where a = 0 and b = '0'; - this works in both

So the thing is, you need to use single quotes while comparing a string column.
Just keep that in mind while writing future code.

Yes. In PostgreSQL the double quotes are used to escape "strange" column names. For instance, I saw a table with a "timestamp" which is also a type in PostgreSQL and to handle that column, you must use double quotes to make sure it works in all cases:

INSERT INTO some_table ("timestamp") VALUES (%d);

If I'm correct, MySQL uses backward quotes as in `int` to handle this special case. Each database uses a different scheme because it is not defined in the SQL92 specs...

Thank you.
Alexis

PostgreSQL strictly follows ANSI SQL for commands in DDL, DCL, TCL & DML categories (limited only to ANSI, there are some additions to it for handing postgre's features). It is MySQL which violates the standards.

And this is the reason why I'm really happy that Drupal 7 abstracts the database layer.. :)

There's no guarantee that there will be no bugs in it either? :D
So, a general theorem: Know SQL & PHP well if you plan to use Drupal & PostgreSQL :D