Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Oct 21, 2009 at 2:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Only connections that are actually using the feature. It doesn't
>> bother me that much --- before 7.4 we had *multiple* round trips
>> involved in a connection start,
> OK, but surely we're not saying that was good? I presume we fixed
> that for a reason and want it to stay fixed.
Well, that was one of multiple things we fixed in the 7.4 protocol
version bump. The *right* way to fix this would probably be another
protocol bump, but I don't see us doing one now ... there are not
enough things broken to justify it, yet. I think that leaving this
as a separate SET until such time as that happens is the most reasonable
thing to do from a project management standpoint. This feature is a
nice-to-have, it's not any kind of "must"; so we should not be boxing
ourselves in with weird kluges we'll have to stay compatible with till
the end of time in order to make it work slightly better.
If you want to avoid an extra round trip, that could probably be managed
with some effort within libpq by not waiting for the response to come
back after the SET. It'd just need to retain some state to remind
itself to discard the first CommandComplete message from the server.
I'm not convinced it's worth the trouble though.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
