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.
In response to
pgsql-hackers by date
|Next:||From: Alvaro Herrera||Date: 2004-07-03 21:22:40|
|Subject: Re: Nested Transaction TODO list|
|Previous:||From: Jeroen T. Vermeulen||Date: 2004-07-03 18:34:18|
|Subject: Re: LinuxTag wrapup|