From: Bruce Badger <bbadger@BadgerSE.com>
To: pgsql-interfaces@postgresql.org
Subject: Re: Frontend - Backend protocol change?
Date: Tue, 02 Jul 2002 19:28:53 +1000
Message-ID: <3D217255.1050207@BadgerSE.com> (raw)
References: <3D1CE5F1.5090402@BadgerSE.com>
<11068.1025316122@sss.pgh.pa.us>
<3D1DA0B1.9060209@BadgerSE.com>
I know it's poor netiquette to respond to myself, and all that, but I
thought I'd keep you updated...
I have a fix for the PostgreSQL Smalltalk library (freely available from
the Cincom public StORE repository (a PostgreSQL database, BTW)) which
works with both versions (!) of the version 0 2 0 0 protocol.
Has there been any progress on this matter at the server end? That is,
has protocol version 0 2 0 0 been returned to a consistent state, or do
we still have multiple versions of the same, er, version?
Thanks,
Bruce
Bruce Badger wrote:
> Tom Lane wrote:
>
>> Bruce Badger <bbadger@BadgerSE.com> writes:
>>
>>
>>> My question is: which is "right" the 7.1 behavior, or the 7.2
>>> behavior?
>>>
>>
>>
>> Hmm ... I'd opine that neither is "right"; the correct behavior would
>> be that you should see no trace of the background INSERT generated
>> by the rule, only of the UPDATE you actually issued.
>>
>> 7.2 seems to be suppressing the INSERT's completion response correctly,
>> but not the CursorResponse.
>>
>> I *think* this might be fixed in current sources, but not sure. Also,
>> there is an open question whether we really like this behavior at all.
>> I'd be interested to see your take on the thread "Queries using rules
>> show no rows modified?" from mid-May in pgsql-hackers. (I'd give a
>> better URL if archive searching weren't currently broken for non-IE
>> browsers.)
>>
>> regards, tom lane
>>
>>
> Thanks for the response :-)
>
> The first thing that springs to mind is that it seems to be a "bad
> thing" for the protocol to change in any way at all without the
> protocol version number being changed too. Given that, my suggested
> "fix" would be (while in no way suggesting what is "right" or not") to
> go back to not suppressing the completion response.
>
> If the existing protocol is deemed to be wrong in some way, then I'd
> be all for having it fixed - at a new protocol version. So I would
> see the fixing process working something like: decide on a new
> protocol version number, decide on what is right, and then roll out
> the new protocol variant alongside the existing one. The debate about
> how long to support the "old" version could then begin.
>
> On the question of what is "right": Clearly there has been some
> lively debate in this area. I am not really steeped in the PostgreSQL
> way of doing things, and it is unlikely that I understand all of the
> issues involved, but FWIW: I think that discarding information may
> not be such a good thing. If I got a result back that said "1 row
> updated (with 2 rows updated as a side-effect)" that might help me to
> tune my app. Certainly, I'd rather have the information than not. So
> barring any issues like the cost of gathering and returning the extra
> info - I'd go for having it. In any case, I'd suggest that any
> changes be made in the context of a new protocol version; and that
> could open the door to a more comprehensive solution, whatever
> philosophy was pursued.
>
> In the mean time, it sounds like I have to figure out a way to make my
> driver tolerant of the fact that sometimes there will be completed
> response message, and sometimes not. :-/ I guess that all the other
> drivers already do this (certainly psql worked with my test case with
> no problems) - is that right?
>
> Before I start hacking, though ... I did see some mention of backing
> out changes & if that meant that the protocol (at version 0 2 0 0)
> would give a consistent set of responses - I'd vote for that. Might
> that happen?
>
> All the best,
> Bruce
>
>
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: bbadger@BadgerSE.com
Subject: Re: Frontend - Backend protocol change?
In-Reply-To: <3D217255.1050207@BadgerSE.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox