Re: Sequence Access Method WIP

On 22/01/15 16:50, Heikki Linnakangas wrote:
> On 01/12/2015 11:33 PM, Petr Jelinek wrote:
>> Second patch adds DDL support. I originally wanted to make it
>> CREATE/DROP SEQUENCE ACCESS METHOD... but that would mean making ACCESS
>> a reserver keyword so I went for CREATE ACCESS METHOD FOR SEQUENCES
>> which does not need to change anything (besides adding METHOD to
>> unreserved keywords).
>> The DDL support uses the DefineStmt infra with some very small change as
>> the sequence ams are not schema qualified, but I think it's acceptable
>> and saves considerable amount of boilerplate.
>
> Do we need DDL commands for this at all? I could go either way on that
> question. We recently had a discussion on that wrt. index access methods
> [1], and Tom opined that providing DDL for creating index access methods
> is not worth it. The extension can just insert the rows into pg_seqam
> with INSERT. Do we expect sequence access methods as extensions to be
> more popular than index access methods? Maybe, because the WAL-logging
> problem doesn't exist. But OTOH, if you're writing something like a
> replication system that needs global sequences as part of it, there
> aren't that many of those, and the installation scripts will need to
> deal with more complicated stuff than inserting a row in pg_seqam.

I don't know about popularity, and I've seen the discussion about
indexes. The motivation for DDL for me was handling dependencies
correctly, that's all. If we say we don't care about that (and allow
DROP EXTENSION even though user has sequences that are using the AM)
then we don't need DDL.

>
> [1] http://www.postgresql.org/message-id/26822.1414516012@sss.pgh.pa.us
>
>> And third patch is gapless sequence implementation updated to work with
>> the new DDL support with some tests added for checking if dependencies
>> work correctly. It also acts as example on how to make custom AMs.
>
> I'll take a look at that to see how the API works, but we're not going
> to include it in the source tree, because it doesn't actually guarantee
> gaplessness. That makes it a pretty dangerous example. I'm sure we can
> come up with a better example that might even be useful. How about a
> Lamport's clock sequence, which advances once per second, in addition to
> when anyone calls nextval() ? Or a remote sequence that uses an FDW to
> call nextval() in a foreign server?
>

I have updated patch ready, just didn't submit it because I am otherwise
busy this week, I hope to get to it today evening or tomorrow morning,
so I'd wait until that with looking at the patch.

The new version (the one that is not submitted yet) of gapless sequence
is way more ugly and probably not best example either but does guarantee
gaplessness (it stores the last value in it's own value table). So I am
not sure if it should be included either...

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services