Re: Global Sequences
От | Tom Lane |
---|---|
Тема | Re: Global Sequences |
Дата | |
Msg-id | 28891.1350408549@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Global Sequences (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Global Sequences
Re: Global Sequences |
Список | pgsql-hackers |
Simon Riggs <simon@2ndQuadrant.com> writes: > On 16 October 2012 17:15, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> So I fully >> expect that we're going to need something different from bog-standard >> CREATE SEQUENCE. > There's no point in that at all, as explained. It's sequences that > need to work. We can already call my_nextval() rather than nextval() > if we want a roll-your own sequence facility and can rewrite > applications to call that, assuming UUID isn't appropriate. I wasn't objecting to the concept of allowing nextval() to have overloaded behaviors; more saying that that wasn't where to start the design process. In particular, the reason proposing a hook first seems backwards is that if we have a catalog-level representation that some sequences are local and others not, we should be using that to drive the determination of whether to call a substitute function --- and maybe which one to call. For instance, I could see attaching a function OID to each sequence and then having nextval() call that function, instead of a hook per se. Or maybe better, invent a level of indirection like a "sequence access method" (comparable to index access methods) that provides a compatible set of substitute functions for sequence operations. If you want to override nextval() for a sequence, don't you likely also need to override setval(), currval(), etc? Not to mention overriding ALTER SEQUENCE's behavior. regards, tom lane
В списке pgsql-hackers по дате отправления: