Re: pg_dump versus SERIAL, round N

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: pg_dump versus SERIAL, round N
Дата
Msg-id 200608201750.k7KHo9f14386@momjian.us
обсуждение исходный текст
Ответ на Re: pg_dump versus SERIAL, round N  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_dump versus SERIAL, round N
Список pgsql-hackers
Tom Lane wrote:
> Andreas Pflug <pgadmin@pse-consulting.de> 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 revisions to our dependency
> mechanisms, which I am not about to undertake now.  And I don't see the
> point anyway.  If you did have a sequence being used to feed multiple
> tables, why would you want it to go away if the number of tables dropped
> transiently to zero?  If you then want to add back another table being
> fed by that sequence, you've lost the state of the sequence.  That's the
> same sort of corner case that prompted us to allow zero-column tables,
> ie, the table can continue to exist even if it momentarily has no
> columns.

Agreed. I think it makes sense that if SERIAL auto-created the column,
dropping the table should remove the sequence, but if the sequence was
created manually, drop table should not drop it automatically.

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?

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump versus SERIAL, round N
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_dump versus SERIAL, round N