-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > If we re-parse from source then we will detect any changes that make the > query visibly incorrect. I don't really see that the user can have any > beef if he continues to use a prepared statement whose source text would > have a valid but incompatible meaning due to changes elsewhere. I see your point about the reparsing. It's what happens anyway for drivers such as DBD::Pg which had to emulate a PREPARE before there actually was one. In effect, the statement is re-parsed every time. So consider me over my initial uneasiness. What about rolling prepares back if they are in a transaction, though? They still have the ability to affect a transaction, despite being partially outside of it: pgf=> begin; BEGIN pgf=> prepare toqualify as select 1 from pg_classs; ERROR: relation "pg_classs" does not exist pgf=> prepare toqualify as select 1 from pg_class; ERROR: current transaction is aborted, commands ignored until end of transaction block pgf=> rollback; ROLLBACK pgf=> begin; BEGIN pgf=> prepare toqualify as select 1 from pg_class; PREPARE pgf=> prepare yourself as select 1 from pg_procc; ERROR: relation "pg_procc" does not exist pgf=> prepare yourself as select 1 from pg_proc; ERROR: current transaction is aborted, commands ignored until end of transaction block pgf=> rollback; ROLLBACK pgf=> deallocate toqualify; DEALLOCATE - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200405032114 -----BEGIN PGP SIGNATURE----- iD8DBQFAlvCyvJuQZxSWSsgRAq00AJ4tvAseEraeOqz/zG83DvIBX8EPiACeObxW oUPFV5t+dbgsVnFIjh8FgMs= =HVkx -----END PGP SIGNATURE-----
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
