Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dcbQX-0002b2-Ft for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Aug 2017 17:57:53 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dcbQX-0001Qn-2d for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Aug 2017 17:57:53 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dcbQV-0001KP-2S for pgsql-hackers@postgresql.org; Tue, 01 Aug 2017 17:57:51 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dcbQS-0002jH-52 for pgsql-hackers@postgresql.org; Tue, 01 Aug 2017 17:57:50 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v71Hvg7S011853; Tue, 1 Aug 2017 13:57:42 -0400 From: Tom Lane To: Robert Haas cc: Andres Freund , "pgsql-hackers@postgresql.org" Subject: Re: Better way to handle suppression of CASCADE detail messages In-reply-to: References: <10766.1501608885@sss.pgh.pa.us> <20170801173922.txyo6nr4j5grgipf@alap3.anarazel.de> Comments: In-reply-to Robert Haas message dated "Tue, 01 Aug 2017 13:48:34 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11851.1501610262.1@sss.pgh.pa.us> Date: Tue, 01 Aug 2017 13:57:42 -0400 Message-ID: <11852.1501610262@sss.pgh.pa.us> List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Robert Haas writes: > On Tue, Aug 1, 2017 at 1:39 PM, Andres Freund 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. Yeah, loss of the causality relationship is the main thing that's bugging me too. If we sorted by OID then in most cases the objects would be listed in creation order, which would likely also have something to do with the dependency order; but it would be different in the same cases that are most likely to be confusing :-( I do not buy Andres' concern about parallelism breaking the test results. We only ever drop objects created in the same test, so their OID ordering would be the same (ie creation order) in every case unless an OID wraparound occurred mid-test, which isn't a situation I feel a need to worry about for this purpose. However, possible loss of user friendliness *is* a valid concern here. Anyway, we don't need a design for this today. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers