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
> > sequen
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 asso
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
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
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
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 wi
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 ext
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
"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
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 sup
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 understan
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, b
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 out
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 A
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
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
> s
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
> anot
Martijn van Oosterhout 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
> could you use o
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 t
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:
http://archives.postgresql
20 matches
Mail list logo
