Re: Frontend - Backend protocol change?
От | Bruce Badger |
---|---|
Тема | Re: Frontend - Backend protocol change? |
Дата | |
Msg-id | 3D1DA0B1.9060209@BadgerSE.com обсуждение исходный текст |
Ответ на | Frontend - Backend protocol change? (Bruce Badger <bbadger@BadgerSE.com>) |
Список | pgsql-interfaces |
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 waspursued. 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
В списке pgsql-interfaces по дате отправления: