Re: Frontend - Backend protocol change? - Mailing list pgsql-interfaces

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
>
>