Re: [HACKERS] Insert result does not match record count
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Insert result does not match record count |
Дата | |
Msg-id | 22395.1391204301@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Insert result does not match record count (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [HACKERS] Insert result does not match record count
|
Список | pgsql-general |
Bruce Momjian <bruce@momjian.us> writes: > On Fri, Jan 31, 2014 at 06:34:27PM +0100, Vik Fearing wrote: >> Unfortunately, I gave up on it as being over my head when I noticed I >> was changing the protocol itself. I should have notified the list so >> someone else could have taken over. > OK, so that brings up a good question. Can we change the protocol for > this without causing major breakage? Tom seems to indicate that it can > be done for 9.4, but I thought protocol breakage was a major issue. Are > we really changing the wire protocol here, or just the type of string we > can pass back to the interface? What I said about it upthread was "this is effectively a protocol change, albeit a pretty minor one, so I can't see back-patching it". The discussion in bug #7766 shows that some client-side code is likely to need fixing, and that such fixing might actually be nontrivial for them. So changing this in a minor release is clearly a bad idea. But I don't have a problem with widening the counters in a major release where we can document it as a potential compatibility issue. I took a quick look and noted that CMDSTATUS_LEN and COMPLETION_TAG_BUFSIZE are set to 64, and have been for quite a long time, so command status string buffer sizes should not be a problem. I think we probably just need to widen es_processed and touch related code. Not sure what else Vik saw that needed doing. regards, tom lane
В списке pgsql-general по дате отправления: