Re: [HACKERS] Better way to handle suppression of CASCADE detailmessages - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [HACKERS] Better way to handle suppression of CASCADE detailmessages
Date
Msg-id 20170801195930.nl2xiksigvggvfwp@alvherre.pgsql
Whole thread Raw
In response to Re: [HACKERS] Better way to handle suppression of CASCADE detailmessages  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund wrote:
> 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.

I'm not sure I buy the idea of ordering by name.  Not all objects are
going to be of the same type, so ordering by name is going to look
strange.

OID order would only have a problem if you run the tests just before OID
wraparound, and the counter wraps in the middle of the test.  To me that
seems a fringe enough situation that we shouldn't worry about it ...  in
a freshly initdb'd cluster it will never behave strangely.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [PATCH] A hook for session start
Next
From: Ildus K
Date:
Subject: Re: [HACKERS] Remove 1MB size limit in tsvector