Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.warning: pg_query() [function.pg-query]: Query failed: ERROR: operator does not exist: character varying = integer at character 61 HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. in /home/synerger/synerger.com/drupal-5/includes/database.pgsql.inc on line 139.
user warning: ERROR: operator does not exist: character varying = integer at character 61 HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. query: UPDATE blocks SET cache = 5 WHERE module = 'book' AND delta = 0 in /home/synerger/synerger.com/drupal-5/modules/system/system.install on line 2036.
The delta field is varchar so the SQL syntax is type incorrect. Patch follows.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 360830_200903041753-0500-D6.patch | 881 bytes | sammys |
| #1 | 360830_200901191428+1100-D6.patch | 824 bytes | sammys |
Comments
Comment #1
sammys CreditAttribution: sammys commentedHere's the patch.
Comment #2
Gábor HojtsyIt would be useful if you'd not mark your own patches ready, especially that this patch was not ready. My first impression was that it should have a comment on why do we do '%d', before someone comes around and "fixes" it to %d. Then I realized that the delta is indeed used for actual strings, so casting it to %d would omit some blocks from being updated properly. Those should pick up their cache values on the next blocks page submit/visit, but still, this query is broken here. So actually migrating to '%s' (and adding a line of comment above saying that delta can be any string) sounds like a better solution.
Comment #3
sammys CreditAttribution: sammys commentedLooks like I selected the wrong status accidentally. What you've said makes sense. I didn't realise it can be used for normal strings along with digits. I'll reroll while watching the next DrupalCon session.
Comment #4
sammys CreditAttribution: sammys commentedHere's the rerolled patch.
Comment #5
Dave ReidComment #6
neilnz CreditAttribution: neilnz commentedThe patch in #4 is correct and works as I'd expect, but since it's in system update hook 6027, and it's up to 6051 already, I think this is too late to help many people.
I think if this has caused any problems, it should be rerolled as a new update hook that mops up anything that was missed.
As #2 mentions, even on MySQL this would have caused the cache settings to be lost for any blocks using string-based deltas.
Also, why is something updating the block table in the system module? Shouldn't this update have been part of the block module?
Comment #7
plj CreditAttribution: plj commentedMany people have not upgraded to Drupal 6 yet, as Drupal 5 is still supported. It is not in vain to fix upgrade problems as long as there are people, who'll have to upgrade!
Besides, at least I did not have this problem in May, when I upgraded one site that run on PostgreSQL 8.1 (the one in Debian Etch). But now I'm upgrading another site that runs on PostgreSQL 8.3 (in Lenny), and ran straight into this. Apparently 8.3 does stricter type checks than 8.1. Sammy's patch, however, works very well, and I hope it gets committed asap.
Comment #8
Gábor HojtsySince this does not apply to D7 (D5 -> D6 updates are removed as usual), I went ahead and committed to Drupal 6. Also, found out that once '%s' is used, it is all natural without an extra comment. Those who wrote the update function originally made a mistake to assume a number field there but it is a string. Thanks!