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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Better way to handle suppression of CASCADE detailmessages
Дата
Msg-id 20170801182328.ei4brmyxeemcsqzs@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Better way to handle suppression of CASCADE detail messages  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Better way to handle suppression of CASCADE detailmessages  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On 2017-08-01 13:48:34 -0400, Robert Haas wrote:
> 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.

I'm not sure that's going to easily be better - won't the oid order in
turn determine the topological order. Which then again isn't very easy
to understand for users.

- Andres



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Better way to handle suppression of CASCADE detail messages
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitorprogression of long running SQL queries/utilities