Re: [HACKERS] Better way to handle suppression of CASCADE detail messages

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Better way to handle suppression of CASCADE detail messages
Дата
Msg-id CA+TgmoZ5CP=DZhyL90TJ6NN1L-7_G8esfLdPRRvpqO6JSYS7kQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Better way to handle suppression of CASCADE detailmessages  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] Better way to handle suppression of CASCADE detail messages  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Better way to handle suppression of CASCADE detailmessages  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Tue, Aug 1, 2017 at 1:39 PM, Andres Freund <andres@anarazel.de> wrote:
> Oid is probably not good enough - with parallel tests and such it's not
> necessarily predicable. Even less so when the tests are run against an
> existing cluster.  Sorting by name would probably be better...

It's arguably more user-friendly, too, although part of me feels like
it would be better to try to preserve the topological ordering in some
way.  If something cascades to foo and from there to bar and from
there to baz to and from there to quux, emitting the messages as

drop cascades to bar
drop cascades to baz
drop cascades to foo
drop cascades to quux

is arguably not going to be too helpful to the user in understanding
the chain of events, however nice it may be for regression testing
purposes.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Better way to handle suppression of CASCADE detailmessages
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()