From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> |
Cc: | "Ashley Cambrell" <ash(at)freaky-namuh(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 7.3 schedule |
Date: | 2002-04-11 16:14:41 |
Message-ID: | 1788.1018541681@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> writes:
> On the other hand, there are already a few reasons to make some
> changes to the FE/BE protocol (NOTIFY messages, transaction state,
> and now possibly PREPARE/EXECUTE -- anything else?).
Passing EXECUTE parameters without having them go through the parser
could possibly be done without a protocol change: use the 'fast path'
function-call code to pass binary parameters to a function that is
otherwise equivalent to EXECUTE.
On the other hand, the 'fast path' protocol itself is pretty horribly
misdesigned, and I'm not sure I want to encourage more use of it until
we can get it cleaned up (see the comments in backend/tcop/fastpath.c).
Aside from lack of robustness, I'm not sure it can work at all for
functions that don't have prespecified types and numbers of parameters.
The FE/BE COPY protocol is also horrible. So yeah, there are a bunch of
things we *could* fix if we were ready to take on a protocol change.
My own thought is this might be better held for 7.4, though. We are
already going to be causing application programmers a lot of pain with
the schema changes and ensuing system-catalog revisions. That might
be enough on their plates for this cycle.
In any case, for the moment I think it's fine to be working on
PREPARE/EXECUTE support at the SQL level. We can worry about adding
a parser bypass for EXECUTE parameters later.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2002-04-11 16:16:34 | Re: help with bison |
Previous Message | Thomas Lockhart | 2002-04-11 16:12:33 | Re: Implicit coercions need to be reined in |