Skip site navigation (1) Skip section navigation (2)

Re: [Re] Re: PREPARE and transactions

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Re] Re: PREPARE and transactions
Date: 2004-07-02 23:17:18
Message-ID: 40E5ECFE.8050606@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Jeroen T. Vermeulen wrote:

>>>Just don't tell me that making
>>>PREPARE respect rollbacks would break compatibility
>>
>>Why not? It's true.
> 
>  
> So many things are true.  But _not_ doing so also breaks compatibility,
> so like I said, there are counterexamples.

This is nonsense. Not changing the current behaviour cannot break 
compatibility, almost by definition.

>>Also: what about the V3 protocol's support for named statements?
> 
> 
> Haven't looked at them (I work on top of libpq),

Please do take a look. The V3 protocol treats the set of named 
statements as part of the connection state, not as anything at the SQL 
statement level. There are also named portals to deal with if your issue 
is that things shouldn't be named.

> So again, I'd like to hear any comments about my pattern-matching
> proposal.  Is there any problem here that it would not solve?  Does anyone
> see a problem in implementing them?

The client has query-lifetime and query-reuse information that the 
server does not have and can't obtain via simple query matching. Also, 
clients need per-query control over use of PREPARE: prepared queries can 
run slower as they must use a more general query plan. I don't see how 
you overcome either of these if the server hides the mechanics of which 
query plans are preserved.

You could implement the pattern-matching logic as a passthrough layer in 
front of the server -- perhaps in something like pgpool? -- and 
translate to PREPARE based on patterns. Then your application can remain 
unaware of the translation to PREPARE for the most part, the only issue 
being name collision which in practice is simple to work around. But I 
don't see why you want this in the main server at all -- it's really a 
bandaid for applications that don't want to precisely control the 
prepared-statement behaviour themselves.

-O

In response to

Responses

pgsql-hackers by date

Next:From: Jeroen T. VermeulenDate: 2004-07-02 23:33:42
Subject: Re: [Re] Re: PREPARE and transactions
Previous:From: Jeroen T. VermeulenDate: 2004-07-02 22:35:22
Subject: Re: [Re] Re: PREPARE and transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group