Re: Global Sequences - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Global Sequences
Date
Msg-id 27496.1350404147@sss.pgh.pa.us
Whole thread Raw
In response to Re: Global Sequences  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Global Sequences  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Global Sequences  (Markus Wanner <markus@bluegap.ch>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 16 October 2012 15:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think this is a fundamentally wrong way to go about doing what you
>> want to do.  It presumes that DDL-level manipulation of global sequences
>> is exactly like local sequences; an assumption that is obviously false.

> The message queue concept doesn't exist at all yet, so when we create
> it we can specify anything we want. That is a different situation and
> hence a different solution. CREATE SEQUENCE is SQL Standard and used
> by SERIAL, many people's SQL, SQL generation tools etc.. My objective
> is to come up with something that makes the standard code work
> correctly in a replicated environment.

I challenge you to find anything in the SQL standard that suggests that
sequences have any nonlocal behavior.  If anything, what you propose
violates the standard, it doesn't make us follow it more closely.

Furthermore, I find it hard to believe that people won't want both
local and global sequences in the same database --- so one way or the
other we need some DDL-level reflection of the difference.

A larger point though is that the various implementation choices you
mentioned probably need to be configurable by DDL options.  I doubt that
it will work well to say "install plugin A to get behavior X, or install
plugin B to get behavior Y, and whichever you choose is not further
configurable, it'll be the same behavior for all sequences".  So I fully
expect that we're going to need something different from bog-standard
CREATE SEQUENCE.  Exactly what isn't clear --- but I think modifying
nextval's behavior is way down the list of concerns.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Bugs in planner's equivalence-class processing
Next
From: Peter Eisentraut
Date:
Subject: Re: Global Sequences