Simon Riggs <si...@2ndquadrant.com> writes: > On 16 October 2012 17:15, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers