This is a discussion on BUG #2079: strage PREPARE/EXECUTE behavior within the pgsql Bugs forums, part of the PostgreSQL category; --> The following bug has been logged online: Bug reference: 2079 Logged by: Yuriy Vostrikoff Email address: mon@lcpi.ru PostgreSQL version: ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| The following bug has been logged online: Bug reference: 2079 Logged by: Yuriy Vostrikoff Email address: mon@lcpi.ru PostgreSQL version: 8.1.0 Operating system: Debian sarge Description: strage PREPARE/EXECUTE behavior Details: EXECUTE return wrong result after ALTER TABLE ALTER COLUMN TYPE. Is this expected behavior? mon=> select version(); version ---------------------------------------------------------------------------- --------------- PostgreSQL 8.1.0 on i386-pc-linux-gnu, compiled by GCC cc (GCC) 3.3.5 (Debian 1:3.3.5-13) (1 row) mon=> \d No relations found. mon=> create table test (col timestamp); CREATE TABLE mon=> insert into test values(current_timestamp); INSERT 0 1 mon=> insert into test values(current_timestamp); INSERT 0 1 mon=> prepare q as select * from test; PREPARE mon=> EXECUTE q; col ---------------------------- 2005-11-30 12:27:49.569859 2005-11-30 12:27:51.463482 (2 rows) mon=> alter table test alter col type text; ALTER TABLE mon=> execute q; col ------------------------------ 123450-10-10 15:43:18.790174 123450-10-10 15:43:18.790174 (2 rows) mon=> select * from test; col ---------------------------- 2005-11-30 12:27:49.569859 2005-11-30 12:27:51.463482 (2 rows) '123450-10-10 15:43:18.790174' is certainly not '2005-11-30 12:27:49.569859'. Same problem with other datatypes. And a second question: why PQprepare() from libpq returns empty PQresult? It's useful to know field number, field types before PQexecutePrepared. ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly |
| ||||
| "Yuriy Vostrikoff" <mon@lcpi.ru> writes: > EXECUTE return wrong result after ALTER TABLE ALTER COLUMN TYPE. Is this > expected behavior? The prepared plan really should be invalidated by the ALTER, but we don't currently have any infrastructure that would allow that to happen. I think Neil Conway is looking into it for 8.2, though. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match |
| Thread Tools | |
| Display Modes | |
|
|