Re: Frontend - Backend protocol change?

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(at)BadgerSE(dot)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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
>