On Tue, Oct 16, 2012 at 1:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Yeah, I like that. That makes it easy to configure your database so
that some sequences have special behavior (which the database designer
can set up however they like) and others can be just vanilla, and the
plugin doesn't have to try to figure out which ones are which (which
was my first concern in reading Simon's original proposal). To make
it even better, add some generic options that can be passed through to
the underlying handler.
So something like:
ALTER SEQUENCE wump SET HANDLER (nextval my_magical_nextval, setval my_magical_setval) OPTIONS
(any_label_you_want_the_handlers_to_get
'some_text_associated_with_the_label', another_label
'some_more_text');
That way you could say, for example, that sequence wump should get its
values from coordinator node 172.24.16.93 and that the global
identifier for this sequence is UUID
e15ea6e6-43d5-4f65-8efd-cf28a14a2d70. That way you can avoid having
to make any assumptions about how local sequence names on particular
nodes are mapped onto global names.
> 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.
This might be better, but it's also possibly more mechanism than we
truly need here. But then again, if we're going to end up with more
than a handful of handlers, we probably do want to do this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
