On Tue, Oct 16, 2012 at 1:29 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers