Re: [Re] Re: PREPARE and transactions - Mailing list pgsql-hackers

From Jeroen T. Vermeulen
Subject Re: [Re] Re: PREPARE and transactions
Date
Msg-id 20040703184449.GS50626@xs4all.nl
Whole thread Raw
In response to Re: [Re] Re: PREPARE and transactions  (Oliver Jowett <oliver@opencloud.com>)
Responses Re: [Re] Re: PREPARE and transactions  (Oliver Jowett <oliver@opencloud.com>)
List pgsql-hackers
On Sat, Jul 03, 2004 at 02:59:58PM +1200, Oliver Jowett wrote:
> 
> I think you mean "between 7.2 and 7.3".
Ah, OK.  I thought PREPARE had been added in 7.4.  My apologies.


> Yes. I see PREPARE/EXECUTE as a SQL-statement-level, connection-local 
> way of getting control over reuse of plans that doesn't otherwise affect 
> the semantics of the query. With the V3 protocol you can also do it at 
> the protocol level rather than the statement level, but it's still the 
> same underlying operation; why should it behave differently?
The real basis of this pattern-matching idea I'm proposing is that the
naming issue (which is semantic) and the reuse of plans (which is an
optimization) could be handled separately.  The next question I think is
whether the two should really share a namespace, and whether the two types
of names should have the same behaviour.  The underlying mechanism would 
remain the same, but once these issues have been decoupled I think SQL
names and protocol-level names are easy to see as different things.


> I'm not too worried, to tell the truth -- the JDBC driver has already 
> moved to using the protocol-level approach, and so long as that doesn't 
> change I'm happy. It just seems to me that the changes you're advocating 
> are going to break more clients than they help (e.g. it would have 
> required nontrivial work on the JDBC driver as of a month ago to deal 
> with the change), and for no convincing reason.

Maybe.  OTOH I find it simply disturbing (as a matter of aesthetics, you
could say) that the application can be messing around with the protocol
underneath the middleware it's supposed to live on top of--the middleware
that should expect to be in control of the backend below the SQL level.


Jeroen



pgsql-hackers by date:

Previous
From: "Jeroen T. Vermeulen"
Date:
Subject: Re: LinuxTag wrapup
Next
From: Alvaro Herrera
Date:
Subject: Re: Nested Transaction TODO list