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
|
Список | 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 по дате отправления: