Re: Better way to handle suppression of CASCADE detail messages

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-08-01T18:23:28Z
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@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


Commits

  1. Suppress less info in regression tests using DROP CASCADE.