ALTER SEQUENCE: Missing feature?
Kind people,
The fine folks in #postgresql brought this up, and it seems like,
well, a bug. In order to make certain kinds of changes on a SEQUENCE,
you have to issue an ALTER TABLE statement. Shouldn't alterations
like RENAME TO, OWNER, etc. to a SEQUENCE all (be able to) go through
ALTER SEQUENCE? What else might this impact?
Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 cell: +1 415 235 3778
Before you try to play the history card, make sure it's in your hand.
david@fetter.org (David Fetter) writes:
The fine folks in #postgresql brought this up, and it seems like,
well, a bug. In order to make certain kinds of changes on a SEQUENCE,
you have to issue an ALTER TABLE statement. Shouldn't alterations
like RENAME TO, OWNER, etc. to a SEQUENCE all (be able to) go through
ALTER SEQUENCE? What else might this impact?
Sequences are tables in some very real senses. I don't see the value in
duplicating code just to allow people to spell TABLE as SEQUENCE in
these commands...
regards, tom lane
On Sun, Feb 01, 2004 at 02:53:18PM -0500, Tom Lane wrote:
david@fetter.org (David Fetter) writes:
The fine folks in #postgresql brought this up, and it seems like,
well, a bug. In order to make certain kinds of changes on a
SEQUENCE, you have to issue an ALTER TABLE statement. Shouldn't
alterations like RENAME TO, OWNER, etc. to a SEQUENCE all (be able
to) go through ALTER SEQUENCE? What else might this impact?Sequences are tables in some very real senses. I don't see the
value in duplicating code just to allow people to spell TABLE as
SEQUENCE in these commands...
I guess it comes down to a philosophical thing. Should people need to
know the PostgreSQL internals like the fact that a SEQUENCE is
currently implemented as a TABLE, or should they just be able to do
reasonable things like call ALTER SEQUENCE when they alter a sequence?
Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 cell: +1 415 235 3778
Sequences are tables in some very real senses. I don't see the
value in duplicating code just to allow people to spell TABLE as
SEQUENCE in these commands...I guess it comes down to a philosophical thing. Should people need to
know the PostgreSQL internals like the fact that a SEQUENCE is
currently implemented as a TABLE, or should they just be able to do
reasonable things like call ALTER SEQUENCE when they alter a sequence?
I would have to second this. From a user, user space programmer, dba
perspective a SEQUENCE is a
SEQUENCE not a table... thus operations such as ALTER that effect the
SEQUENCE should
use ALTER SEQUENCE.
Sincerely,
Joshua D. Drake
Cheers,
D
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
"Joshua D. Drake" <jd@commandprompt.com> writes:
I guess it comes down to a philosophical thing. Should people need to
know the PostgreSQL internals like the fact that a SEQUENCE is
currently implemented as a TABLE, or should they just be able to do
reasonable things like call ALTER SEQUENCE when they alter a sequence?I would have to second this.
Well, (1) we are not going to be able to hide the implementation fact
entirely --- for instance, you can't readily hide that they share the
same namespace, so that you can't have a table and a sequence of the
same name. People will have to learn this fact about sequences
eventually. For that matter we advertise it by using "SELECT * FROM
sequence" as a way of inspecting sequence parameters; will you invent
a replacement for that?
(2) If you do want to hide it at the cosmetic level you will have more
work to do than this. ALTER TABLE also works (in some variants) on
indexes; will you also invent ALTER INDEX? See also GRANT/REVOKE; will
you change that syntax too? Will you invent new privilege names for
sequences to hide the overlap with table privilege types? Will you
forbid the old spellings of all this stuff (thereby breaking existing
pg_dump files)?
It just seems like a much bigger can of worms to open than the payback
would justify.
regards, tom lane
Tom Lane wrote:
"Joshua D. Drake" <jd@commandprompt.com> writes:
I guess it comes down to a philosophical thing. Should people need to
know the PostgreSQL internals like the fact that a SEQUENCE is
currently implemented as a TABLE, or should they just be able to do
reasonable things like call ALTER SEQUENCE when they alter a sequence?I would have to second this.
same name. People will have to learn this fact about sequences
eventually. For that matter we advertise it by using "SELECT * FROM
sequence" as a way of inspecting sequence parameters; will you invent
a replacement for that?
No because PostgreSQL uses SELECT for many things, including the
execution of functions.
(2) If you do want to hide it at the cosmetic level you will have more
work to do than this. ALTER TABLE also works (in some variants) on
indexes; will you also invent ALTER INDEX?
No because from a logical (at least mine) perspective, Indices are a
table only thing. Sequences
are not always used in correlation with a table.
See also GRANT/REVOKE; will
you change that syntax too?
I am not sure how this is even relevant as GRANT / REVOKE can be applied
to a specific object?
Will you invent new privilege names for
sequences to hide the overlap with table privilege types? Will you
forbid the old spellings of all this stuff (thereby breaking existing
pg_dump files)?It just seems like a much bigger can of worms to open than the payback
would justify.
That may be the case but couldn't you just have a generic function
within C that just calls out the
appropriate parameters per the relation? E.g; it knows that ALTER
SEQUENCE is actually
ALTER TABLE minus these six (whatever six they may be) parameters?
Sincerely,
Joshua D. Drake
regards, tom lane
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL