Re: [HACKERS] Better way to handle suppression of CASCADE detail messages

2017-08-01 Thread Alvaro Herrera
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 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

Re: [HACKERS] Better way to handle suppression of CASCADE detail messages

2017-08-01 Thread Andres Freund
On 2017-08-01 13:48:34 -0400, Robert Haas wrote: > 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 woul

Re: [HACKERS] Better way to handle suppression of CASCADE detail messages

2017-08-01 Thread Tom Lane
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

Re: [HACKERS] Better way to handle suppression of CASCADE detail messages

2017-08-01 Thread Robert Haas
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

Re: [HACKERS] Better way to handle suppression of CASCADE detail messages

2017-08-01 Thread Andres Freund
Hi, On 2017-08-01 13:34:45 -0400, Tom Lane wrote: > 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. Oid is probably not good enough - with parallel tests and such it's n