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