Re: Frontend - Backend protocol change?

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