Re: Precedence of standard comparison operators

On Wed, Mar 11, 2015 at 7:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kevin Grittner <kgrittn(at)ymail(dot)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