| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Phil Frost" <indigo(at)bitglue(dot)com> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #2512: pg_dump produces unrestorable output when table and serial sequence are not in the same schema |
| Date: | 2006-07-04 20:17:45 |
| Message-ID: | 26258.1152044265@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"Phil Frost" <indigo(at)bitglue(dot)com> writes:
> Creating the database:
> test=> create schema private;
> test=> create table o(i serial primary key);
> test=> alter sequence o_i_seq set schema private;
I would argue that the bug is we allow you to do the above ;-).
It's not really sane to move a serial sequence out of its owning table's
schema (compare the situation for indexes). If you play with it you'll
find that "alter table o set schema private" will move the sequence too
... but the above case isn't checked for.
This ties into the long-running discussion on whether a serial column
should be entirely a black box or not. Currently there are quite a few
things you could do to the underlying sequence object that pg_dump would
fail to dump/restore correctly. One school of thought says we'd be best
off to forbid any direct manipulation of the sequence object.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yann PICHOT | 2006-07-05 06:57:00 | Fwd: Diffrence between 8.0.3 and 8.1.3 |
| Previous Message | Tom Lane | 2006-07-04 18:15:54 | Re: query very slow when enable_seqscan=on |