On Sat, 2006-08-19 at 16:01 -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The only complaint I can see is that someone
who wants pg_dump to dump out SERIAL so it appears just as he created
the table, doesn't get that. Could we have pg_dump do that if the
sequences all
Tom Lane wrote:
Almost everything I just said is already how it works today; the
difference is that today you do not have the option to drop t1 without
dropping the sequence, because there's no (non-hack) way to remove the
dependency.
As far as I understand your proposal I like it, but
Andreas Pflug wrote:
Tom Lane wrote:
Almost everything I just said is already how it works today; the
difference is that today you do not have the option to drop t1 without
dropping the sequence, because there's no (non-hack) way to remove the
dependency.
As far as I understand your
Andreas Pflug [EMAIL PROTECTED] writes:
As far as I understand your proposal I like it, but I'd like to insure
that the situation where a sequence is used by multiple tables is
handled correctly. There _are_ databases that reuse a sequence for
multiple serial-like columns, and pgadmin supports
Andrew Dunstan [EMAIL PROTECTED] writes:
If we were implementing serial from scratch, I would be arguing that the
underlying sequence should be merely an implementation detail that should
be totally hidden, and sequences used explicitly should be kept as a
separate concept. Then many of these
Tom Lane wrote:
If you insist on initially creating the sequence by saying SERIAL for
the first of the tables, and then saying DEFAULT nextval('foo_seq')
for the rest, then under both 8.1 and my proposal you'd not be able to
drop the first table without dropping the sequence (thus requiring
Andreas Pflug [EMAIL PROTECTED] writes:
I basically doubt the concept of a single owner. I'd expect a sequence
to be dropped from cascaded table dropping, if that was the last usage
and dependencies existed. This would probably mean multiple owners.
That's not going to happen without extensive
Bruce Momjian [EMAIL PROTECTED] writes:
What method will people use to see if a sequence used as a default is
one that was created by SERIAL, and will be dropped by drop table, or
manually created? How does that distinction show up in pg_dump?
Hm. It will show in pg_dump because there will
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
I basically doubt the concept of a single owner. I'd expect a sequence
to be dropped from cascaded table dropping, if that was the last usage
and dependencies existed. This would probably mean multiple owners.
That's not going to
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
What method will people use to see if a sequence used as a default is
one that was created by SERIAL, and will be dropped by drop table, or
manually created? How does that distinction show up in pg_dump?
Hm. It will show in
Bruce Momjian [EMAIL PROTECTED] writes:
Also, if someone restores one table, does the sequence come with it like
it does now with SERIAL?
Hm, probably not. I do have pg_dump set to force dumping of the
sequence if you try to dump just its table, but it'd be possible to tell
pg_restore (via -l)
Bruce Momjian [EMAIL PROTECTED] writes:
What method will people use to see if a sequence used as a default is
one that was created by SERIAL, and will be dropped by drop table, or
manually created? How does that distinction show up in pg_dump?
BTW, it's easy to see if a column has an
We have still another complaint here:
http://archives.postgresql.org/pgsql-bugs/2006-08/msg00109.php
about pg_dump failing to cope nicely with any slightly-unusual
condition related to a SERIAL column. We've had previous
discussions about this, most recently this thread:
On Sat, Aug 19, 2006 at 11:47:39AM -0400, Tom Lane wrote:
ALTER SEQUENCE foo_bar_seq SERIAL FOR foo.bar;
I like it, and I imagine users will love it too. Only one question:
will a sequence be limited to belonging to one table at a time, or
could you use one sequence for multiple tables and use
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Aug 19, 2006 at 11:47:39AM -0400, Tom Lane wrote:
ALTER SEQUENCE foo_bar_seq SERIAL FOR foo.bar;
I like it, and I imagine users will love it too. Only one question:
will a sequence be limited to belonging to one table at a time, or
I wrote:
Also, after thinking about the existing behavior of ALTER TABLE OWNER
(it tries to keep ownership of dependent sequences equal to the table's
ownership), we'd have to either abandon that or insist that you can
only link a sequence to a table having the same owner. So that's
another
Tom Lane wrote:
Basically this change would mean that you'd be allowed to DROP the
sequence with CASCADE (hence removing all the DEFAULT expressions that
use it) without being forced to drop the owning column as such. That
seems to square better with the idea that the column owns the
Bruce Momjian [EMAIL PROTECTED] writes:
Our two SERIAL TODO items are:
* %Disallow changing DEFAULT expression of a SERIAL column?
This should be done only if the existing SERIAL problems cannot be
fixed.
* %Disallow ALTER SEQUENCE changes for
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Our two SERIAL TODO items are:
* %Disallow changing DEFAULT expression of a SERIAL column?
This should be done only if the existing SERIAL problems cannot be
fixed.
* %Disallow ALTER SEQUENCE
Bruce Momjian [EMAIL PROTECTED] writes:
The only complaint I can see is that someone
who wants pg_dump to dump out SERIAL so it appears just as he created
the table, doesn't get that. Could we have pg_dump do that if the
sequences all match the creation (weren't modified)?
pg_dump's output
20 matches
Mail list logo
