On Wed, Mar 11, 2015 at 7:49 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Kevin Grittner <kgri...@ymail.com> writes: >> If there are no false positives, turning it on is zero impact >> (except for any performance impact involved in detecting the >> condition) for those who have no problems. That will probably be >> the vast majority of users. The question is, do we want to quietly >> do something new and different for the small percentage of users >> who will have a problem, and leave it to them to find out about >> this setting and turn on the feature that tells them where the >> problems are? Or would it be more friendly to show the issues so >> they can resolve them, and then turn off the warnings once they are >> satisfied? > > FWIW, there *are* some especially-corner-casey false positives, > as I noted upthread. I think the odds of people hitting them > are remarkably low, which is why I wasn't willing to invest the > additional code needed to try to make them all go away. I doubt > that this consideration is worth worrying about as we decide > whether the warnings should be on by default ... but if you're > going to make an argument from an assumption of no false positives, > it's wrong.
Just out of curiosity, does this change create a dump-and-reload hazard? Like if I pg_upgrade my cluster, will the output of pg_dump potentially be sufficiently under-parenthesized that reload will create a non-equivalent database? -- 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
