Re: PREPARE and transactions

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)