On 2013-11-15 20:08:30 +0200, Heikki Linnakangas wrote: > It's pretty hard to review the this without seeing the "other" > implementation you're envisioning to use this API. But I'll try:
We've written a distributed sequence implementation against it, so it works at least for that use case. While certainly not release worthy, it still might be interesting to look at. http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=blob;f=contrib/bdr/bdr_seq.c;h=c9480c8021882f888e35080f0e7a7494af37ae27;hb=bdr bdr_sequencer_fill_sequence pre-allocates ranges of values, bdr_sequence_alloc returns them upon nextval(). > I wonder if the level of abstraction is right. The patch assumes that the > on-disk storage of all sequences is the same, so the access method can't > change that. But then it leaves the details of actually updating the on-disk > block, WAL-logging and all, as the responsibility of the access method. > Surely that's going to look identical in all the seqams, if they all use the > same on-disk format. That also means that the sequence access methods can't > be implemented as plugins, as plugins can't do WAL-logging. Well, it exposes log_sequence_tuple() - together with the added "am private" column of pg_squence that allows to do quite a bit of different things. I think unless we really implement pluggable RMGRs - which I don't really see coming - we cannot be radically different. > The comment in seqam.c says that there's a private column reserved for > access method-specific data, called am_data, but that seems to be the only > mention of am_data in the patch. It's amdata, not am_data :/. Directly at the end of pg_sequence. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
