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
