After installing module, setting up vocabulary and blocks. I get the following when trying to load page with block on it:

* warning: pg_query() [function.pg-query]: Query failed: ERROR: syntax error at or near "views" at character 43 in /var/www/virtualhosts/www.devzuz.com/htdocs/includes/database.pgsql.inc on line 125.
* user warning: query: SELECT n.nid, n.title, td.name, n.created views FROM node n INNER JOIN term_node tn ON n.nid = tn.nid INNER JOIN term_data td ON tn.tid = td.tid WHERE td.tid = 1 AND (n.created > unix_timestamp(curdate())-90*86400) AND (n.status = 1) ORDER BY n.created desc, n.changed desc LIMIT 5 OFFSET 0 in /var/www/virtualhosts/www.devzuz.com/htdocs/includes/database.pgsql.inc on line 144.

That does not appear to be a valid SQL query.

CommentFileSizeAuthor
#2 taxonews.module_0.patch1.65 KBfgm

Comments

fgm’s picture

fgm
Primary language French
Location Paris, France
commented
Status: Active » Postponed (maintainer needs more info)

This query may indeed be specific to MySQL, and I don't have a PGSQL installation to try to fix it.

This being said, since the problem appears to be at column 43, it might be a problem with the column aliasing syntax: try replacing n.created views by n.created as views. It might fix the problem, or move it to another part of the query, and report whether this changes the outcome.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented
Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new taxonews.module_0.patch1.65 KB

You can try the attached patch

fgm’s picture

fgm
Primary language French
Location Paris, France
commented
Priority: Critical » Normal

There is a similar patch in the 6.x branch at http://drupal.org/node/183167

Also, removing criticality because you can work around the issue by using MySQL instead of PGSQL.

BartVB’s picture

BartVB commented

(ran into 'osinet' on IRC this morning who is having the same problem). It seems like Postgres doesn't support these date functions:
http://drupal.org/node/122801#comment-209020

But IMO the proper way to fix this is moving all the date functions out of the query altogether. When calculating these dates dynamically it's almost impossible for MySQL to use any indices and it needs to do the calculation on every row it scans.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented
Status: Needs review » Fixed

The discussion with BartVB this morning led to further changes to the D6 branch, backported to D5.

This problem and others are supposed to be fixed in today's version v1.10.6.5

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)