Обсуждение: Re: [PATCHES] ALTER SEQUENCE
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)
or even
ALTER SERIAL ON blah(a)...
Which would allow us to dump tables in an environment where you do now know
exactly what the generated name will be...
Chris
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@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
Rod Taylor <rbt@rbt.ca> writes:
> Might get somewhere by making a special domain thats marked as being
> serial, and using that in the column.
I recall some discussion last year about making serial et al. into
domains over int4 and int8, rather than their current utter-hack
implementation. Can't recall if we found a problem with the idea,
or no one got around to doing it, or it just didn't seem to clean
things up enough to be worth the trouble. (AFAICS you'd still need
special-case code to set up the appropriate default expression for
each column; the domain constraint mechanism wouldn't handle that
for you.)
Seems worth looking at, though.
regards, tom lane
On Tue, 2003-03-04 at 19:14, Tom Lane wrote:
> Rod Taylor <rbt@rbt.ca> writes:
> > Might get somewhere by making a special domain thats marked as being
> > serial, and using that in the column.
>
> I recall some discussion last year about making serial et al. into
> domains over int4 and int8, rather than their current utter-hack
> implementation. Can't recall if we found a problem with the idea,
> or no one got around to doing it, or it just didn't seem to clean
> things up enough to be worth the trouble. (AFAICS you'd still need
> special-case code to set up the appropriate default expression for
> each column; the domain constraint mechanism wouldn't handle that
> for you.)
Slightly different thought. I had actually submitted a patch for the
above, but would have to dig through the archives to determine what the
problem was.
CREATE TABLE tab (column SERIAL);
Generates:
table(column serial_table_column)
domain serial_table_column as int4 default nextval("serial_table_column")
Sequence serial_table_column.
Now, rather than having knowedge of the contents of nextval, we simply
trace the dependencies of the column through the domain to the sequence
-- since these will be known to exist.
Thus the below command could function fairly easily on serials:
ALTER SEQUENCE ON table(column)
The alternative is to simply implement the proposed 200N sequence
generator spec, which includes 'NEXT VALUE FOR <sequence>'.
With that in place, our default would then depend on the sequence, and
the ALTER SEQUENCE ON table(column) would function.
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
Does it make sense to avoid sequence name collisions if applications
have to refer to sequence names directly? I mean, I can imagine a case
where a restore would return a sequence name that is different from the
one that dumped it. pg_dump may be hacked to fix that (look up the
sequence for the column) but what about applications. Seems any real
solution is going to need removal of direct sequence name references in
applications.
---------------------------------------------------------------------------
Rod Taylor wrote:
-- Start of PGP signed section.
> 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@rbt.ca>
>
> PGP Key: http://www.rbt.ca/rbtpub.asc
-- End of PGP section, PGP failed!
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
On Fri, 2003-03-07 at 11:27, Bruce Momjian wrote: > Does it make sense to avoid sequence name collisions if applications > have to refer to sequence names directly? I mean, I can imagine a case Not at all. Hence the thought that we might create syntax to allow applications to refer to the table / column that the sequence (SERIAL) is on. This would hide the internal representation of a SERIAL... -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc