Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] ALTER SEQUENCE

From: Rod Taylor <rbt(at)rbt(dot)ca>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] ALTER SEQUENCE
Date: 2003-03-04 16:16:20
Message-ID: 1046794579.15229.59.camel@jester (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackerspgsql-patches
On Mon, 2003-03-03 at 20:47, Christopher Kings-Lynne wrote:
> Hey, with this new ALTER SEQUENCE patch, how about this for an idea:
> 
> I submitted a patch to always generate non-colliding index and sequence
> names.  Seemed like an excellent idea.  However, 7.3 dumps tables like this:
> 
> CREATE TABLE blah
>     a SERIAL
> );
> 
> SELECT SETVAL('blah_a_seq', 10);
> 
> Sort of thing...
> 
> How about we add a new form to ALTER SEQUENCE <sequence> ...?
> 
> ALTER SEQUENCE ON blah(a) CURRVAL 10.... (or whatever the syntax is)

The spec proposes:

ALTER SEQUENCE <sequence> RESTART WITH <value>;


I suppose (since SERIAL is nonstandard anyway) we could do:

ALTER SEQUENCE ON table(column) RESTART WITH <value>;

The problem is that we really don't have an easy way of determining if
there is a sequence on table(column) to start with and ONLY that table.

I don't think I'd want to allow that on user sequences at all because
they're often used in stranger ways, and the user doing the alteration
may not know that.


As far as getting dependencies on the sequence, the currently proposed
method of retrieving the next value of a sequence generator is 'NEXT
VALUE FOR <sequence>' -- but Tom isn't going to like that :)


Might get somewhere by making a special domain thats marked as being
serial, and using that in the column.  Create the sequence and tie it to
the domain.  Now you know the sequence tied to the column (because it's
on the domain).  Just disallow 'special' serial sequences & domains to
be used in other ways.

Prevention of the domain from being altered would also help, as you can
then prevent the default from changing.

-- 
Rod Taylor <rbt(at)rbt(dot)ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

In response to

Responses

pgsql-hackers by date

Next:From: Brian WalkerDate: 2003-03-04 19:21:15
Subject: Problem with foreign keys (performance and deadlocks)
Previous:From: Chris SuttonDate: 2003-03-04 15:03:59
Subject: Best setup for RAM drive

pgsql-patches by date

Next:From: gregDate: 2003-03-04 19:50:12
Subject: Re: XML ouput for psql
Previous:From: Tom LaneDate: 2003-03-04 15:22:25
Subject: Re:

pgsql-general by date

Next:From: Stephan SzaboDate: 2003-03-04 16:21:30
Subject: Re: foreign key constraint
Previous:From: Tom LaneDate: 2003-03-04 16:14:58
Subject: Re: foreign key constraint

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group