Posted by stodge on June 30, 2009 at 12:19am
| Project: | Event |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | reviewed & tested by the community |
Issue Summary
I stumbled across an error:
* warning: pg_query() [function.pg-query]: Query failed: ERROR: operator does not exist: character varying = integer LINE 1: UPDATE users SET timezone_id = 308 WHERE timezone = -14400 A... ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. in /var/www/sites/project/includes/database.pgsql.inc on line 139.
* user warning: query: UPDATE users SET timezone_id = 308 WHERE timezone = -14400 AND timezone_id = 0 in /var/www/sites/project/sites/all/modules/event/event.module on line 275.
Comments
#1
does pgsql take exception on the negative value for the int?
#2
#3
Postgres 8.4
User-configurable time zones:
+ Enabled
When enabled, users can set their own time zone
and
* warning: pg_query() [function.pg-query]: Query failed: ERROR: value too long for type character varying(8) in D:\BitNami WAPPStack\apache2\htdocs\blogmybaby\includes\database.pgsql.inc on line 139.
* user warning: query: UPDATE users SET timezone = '322|14400', name = 'luk911', mail = 'luk911@mail.ru', status = '1', data = 'a:7:{s:17:"messaging_default";s:4:"mail";s:27:"notifications_send_interval";s:1:"0";s:18:"notifications_auto";i:0;s:14:"picture_delete";i:0;s:14:"picture_upload";s:0:"";s:7:"contact";i:0;s:13:"form_build_id";s:37:"form-21643c66a27321b15e39b51d90609bf0";}' WHERE uid = 1 in D:\BitNami WAPPStack\apache2\htdocs\blogmybaby\modules\user\user.module on line 247.
#4
The issue is the timezone is declared as varchar(8) and the query is supplying an integer. There is no automatic type conversion, so the query should be
db_query('UPDATE {users} SET timezone_id = %d WHERE timezone = \'%d\' AND timezone_id = 0', timezone_id, $user->timezone);Note the quotes around the timezone value.
#5
I'm not sure if I should create a separate item against 5.x-2.x-dev, but the problem is present there, which is what my previous post was testing. I'm attaching a patch for 5.x-2.x-dev, but it may apply to 6.x also.
#6
Here is a patch against 6.x
#7
Changing status to hopefully trigger some action.
#8
I am also using Postgres 8.4 with D6 and patch in #6 worked perfectly.
#9
Almost 5 weeks without bad reviews, I guess it can be set as reviewed.