Running the sample on my system I noticed something that might explain
the problem.
If you configure PostgreSQL to log statements, you can see the same thing.
In the sample provided, PostgreSQL is not asked to prepare a query.
If we change the call from prepare_cached to prepare it is.
Consequently, when it comes to actually executing thequery, the
prepared handle that is called on PostgreSQL isn't found.
THe following log messages may be helpful:
LOG: statement: DROP TABLE test_table
LOG: statement: CREATE table test_table (
id SERIAL PRIMARY KEY,
foo integer,
bar text
)
NOTICE: CREATE TABLE will create implicit sequence
"test_table_id_seq" for serial column "test_table.id"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"test_table_pkey" for table "test_table"
LOG: statement: PREPARE dbdpg_p10098_1 AS SELECT id, foo, bar,
baz FROM test_table WHERE id = $1
ERROR: column "baz" does not exist
LOG: statement: SELECT version()
LOG: statement: ALTER TABLE test_table ADD COLUMN baz boolean
ERROR: prepared statement "dbdpg_p10098_1" does not exist
Now, if I change the call from prepare_cached to prepare, we get
different log messages:
NOTICE: CREATE TABLE will create implicit sequence
"test_table_id_seq" for serial column "test_table.id"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"test_table_pkey" for table "test_table"
LOG: statement: PREPARE dbdpg_p10075_1 AS SELECT id, foo, bar,
baz FROM test_table WHERE id = $1
ERROR: column "baz" does not exist
LOG: statement: SELECT version()
LOG: statement: ALTER TABLE test_table ADD COLUMN baz boolean
LOG: statement: PREPARE dbdpg_p10075_1 AS SELECT id, foo, bar,
baz FROM test_table WHERE id = $1
LOG: statement: <BIND>
LOG: statement: EXECUTE <unnamed> [PREPARE: SELECT id, foo,
bar, baz FROM test_table WHERE id = $1
]
LOG: statement: DEALLOCATE dbdpg_p10075_1
Note that the incorrect behavior here is trying to access a prepared
query which hasn't been prepared....
Best Wishes,
Chris Travers
