Re: [GENERAL] currval and DISCARD ALL
От | Tom Lane |
---|---|
Тема | Re: [GENERAL] currval and DISCARD ALL |
Дата | |
Msg-id | 12538.1366237053@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [GENERAL] currval and DISCARD ALL (Marko Kreen <markokr@gmail.com>) |
Ответы |
Re: [GENERAL] currval and DISCARD ALL
Re: [GENERAL] currval and DISCARD ALL |
Список | pgsql-hackers |
Marko Kreen <markokr@gmail.com> writes: > On Tue, Apr 16, 2013 at 05:09:19PM -0400, Tom Lane wrote: >> Bruce Momjian <bruce@momjian.us> writes: >>> I think his point is why don't we clear currval() on DISCARD ALL? I >>> can't think of a good reason we don't. >> Because we'd have to invent a new suboperation DISCARD SEQUENCES, >> for one thing, in order to be consistent. I'd rather ask why it's >> important that we should throw away such state. It doesn't seem to >> me to be important enough to justify a new subcommand. > "consistency" is a philosophical thing. No, it's a critical tool in complexity management. When you're dealing with systems as complicated as a database, every little non-orthogonal detail adds up. DISCARD ALL has a clear definition in terms of simpler commands, and it's going to stay that way. Either this is worth a subcommand, or it's not worth worrying about at all. > But currval() is quite noticeable thing that DISCARD ALL should clear. If it were as obvious and noticeable as all that, somebody would have noticed before now. We've had DISCARD ALL with its current meaning since 8.3, and nobody complained in the five-plus years since that shipped. At this point, even if a concrete case were made why DISCARD ALL should clear currval (and I repeat that no credible case has been made; nobody has for example pointed to a reasonably-well-designed application that this breaks), there would be a pretty strong backwards-compatibility argument not to change it. regards, tom lane
В списке pgsql-hackers по дате отправления: