[HACKERS] Better way to handle suppression of CASCADE detail messages - Mailing list pgsql-hackers

From Tom Lane
Subject [HACKERS] Better way to handle suppression of CASCADE detail messages
Date
Msg-id 10766.1501608885@sss.pgh.pa.us
Whole thread Raw
Responses Re: [HACKERS] Better way to handle suppression of CASCADE detailmessages  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
In various places in the regression tests, we want to suppress DROP
CASCADE's detail messages because of the fact that they don't always
come out in the same order.  I noticed that some places deal with that
by adjusting client_min_messages while others use "\set VERBOSITY terse".
I think that the latter approach is superior, because with it you still
get to see the basic notice message, something like
NOTICE:  drop cascades to 17 other objects
In this way, the test at least verifies that the expected number of
objects get dropped, even if we aren't checking their precise identities.

So, barring objection, I'm going to run around and change all the tests
that use client_min_messages for this purpose to use VERBOSITY instead.

BTW, in the long run maybe we should instead make the CASCADE message
ordering more predictable, perhaps by sorting the objects by OID.
But that's not a job for beta time.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitorprogression of long running SQL queries/utilities
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] More flexible LDAP auth search filters?