Jeroen T. Vermeulen wrote:
> Well, except prepared statements apparently; I'm not sure why they are
an
> exception.
>
> When I say "within a transaction" as opposed to outside a transaction,
I
> mean of course an explicit transaction. If you want a prepared
statement
> to last throughout the session, I'd say it stands to reason that you
> create it outside a transaction--in unfettered session context, so to
> speak. I can't see how that would be either less intuitive or harder
to
> program in the client.
I disagree. Lots of people use prepared statements for all kinds of
different reasons. A large percentage of them do not need or make use
of explicit transactions. Having to continually rebuild the statement
would be a hassle. The caching mechanism also seems like extra work for
little result (to be fair, I like the idea of multiple backends being
able to make use of the same plan). Generic routines can just always
wrap the prepare statement in a subtransaction, which now allows safety
until such time that a create or replace version becomes available,
Merlin
p.s. Is this correct behavior? A DROP TABLE gives a missing oid error
which is fine, but I don't like this much:
cpc=# create table test (a int, b int, c int);
CREATE TABLE
cpc=# prepare p (int) as select * from test;
PREPARE
cpc=# execute p(0);a | b | c
---+---+---
(0 rows)
cpc=# alter table test drop column a;
ALTER TABLE
cpc=# execute p(0);a | b | c
---+---+---
(0 rows)