|
Home > Archive > PostgreSQL Bugs > November 2005 > BUG #2079: strage PREPARE/EXECUTE behavior
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
BUG #2079: strage PREPARE/EXECUTE behavior
|
|
| Yuriy Vostrikoff 2005-11-30, 1:24 pm |
|
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_times
tamp);
INSERT 0 1
mon=> insert into test values(current_times
tamp);
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
| |
| Tom Lane 2005-11-30, 1:24 pm |
| "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
|
|
|
|
|