Skip site navigation (1) Skip section navigation (2)

Re: Frontend - Backend protocol change?

From: Bruce Badger <bbadger(at)BadgerSE(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Frontend - Backend protocol change?
Date: 2002-06-29 11:57:37
Message-ID: 3D1DA0B1.9060209@BadgerSE.com (view raw or flat)
Thread:
Lists: pgsql-interfaces
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







In response to

Responses

pgsql-interfaces by date

Next:From: Tom LaneDate: 2002-06-30 00:02:32
Subject: Re: large objects
Previous:From: Cedar CoxDate: 2002-06-29 11:27:23
Subject: large objects

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group