Re: [HACKERS] Better way to handle suppression of CASCADE detail messages
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 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 Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Better way to handle suppression of CASCADE detail messages
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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Better way to handle suppression of CASCADE detail messages
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
Re: [HACKERS] Better way to handle suppression of CASCADE detail messages
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. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Better way to handle suppression of CASCADE detail messages
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 not necessarily predicable. Even less so when the tests are run against an existing cluster. Sorting by name would probably be better... Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
