From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Better way to handle suppression of CASCADE detail messages |
Date: | 2017-08-01 18:23:28 |
Message-ID: | 20170801182328.ei4brmyxeemcsqzs@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-08-01 18:26:23 | Re: [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities |
Previous Message | Tom Lane | 2017-08-01 17:57:42 | Re: Better way to handle suppression of CASCADE detail messages |