Re: Global Sequences - Mailing list pgsql-hackers

On 16 October 2012 17:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

No need for challenge, I agree, the SQL standard doesn't speak about
that. I didn't say it did.

> If anything, what you propose
> violates the standard,

And so that doesn't follow, but anyway...

> it doesn't make us follow it more closely.

I wasn't arguing that my proposal did that (made us follow standard
more closely).

My point is that application code exists that expects sequences to
Just Work, and so the aim of the proposal was to do that in a
replicated environment as well as single node.

> 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.

Agreed, which is why I proposed some DDL-level syntax. Was that OK?

> 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".

Again, I accept that as of my last post, and I proposed syntax to provide it.

> So I fully
> expect that we're going to need something different from bog-standard
> CREATE SEQUENCE.

There's no point in that at all, as explained. It's sequences that
need to work. We can already call my_nextval() rather than nextval()
if we want a roll-your own sequence facility and can rewrite
applications to call that, assuming UUID isn't appropriate.

Please don't force people to rewrite their applications; it might not
go in the direction we want.

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