Re: ERROR: prepared statement "dbdpg_p13754_3" does not exist

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