Re: operator dependency of commutator and negator, redux

On Thu, Dec 20, 2012 at 10:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Brendan Jurd <direvus(at)gmail(dot)com> writes:
>> On 20 December 2012 11:51, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> While reconsidering the various not-too-satisfactory fixes we thought of
>>> back then, I had a sudden thought. Instead of having a COMMUTATOR or
>>> NEGATOR forward reference create a "shell" operator and link to it,
>>> why not simply *ignore* such references? Then when the second operator
>>> is defined, go ahead and fill in both links?
>
>> Ignore with warning sounds pretty good. So it would go something like this?
>
>> # CREATE OPERATOR < (... COMMUTATOR >);
>> WARNING: COMMUTATOR > (foo, foo) undefined, ignoring.
>> CREATE OPERATOR
>
>> # CREATE OPERATOR > (... COMMUTATOR <);
>> CREATE OPERATOR
>
> I was thinking a NOTICE at most. If it's a WARNING then restoring
> perfectly valid pg_dump files will result in lots of scary-looking
> chatter. You could make an argument for printing nothing at all,
> but that would probably mislead people who'd fat-fingered their
> COMMUTATOR entries.

What about jiggering the dump so that only the second of the two
operators to be dumped includes the COMMUTATOR clause? Or even adding
a separate ALTER OPERATOR < COMMUTATOR > statement (or something of
the sort) that pg_dump can emit as a separate item. Even a NOTICE in
pg_dump seems like too much chatter (witness recent quieting of some
other NOTICE messages we've all grown tired of) but silently ignoring
the problem doesn't seem smart either, for the reason you mention.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company