Re: operator dependency of commutator and negator, redux

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: operator dependency of commutator and negator, redux
Дата
Msg-id CA+TgmoZh+ePzHM8cV0n=UMRugzCFCd1XDudN0584bdkPK5_cxA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: operator dependency of commutator and negator, redux  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: operator dependency of commutator and negator, redux
Re: operator dependency of commutator and negator, redux
Список pgsql-hackers
On Thu, Dec 20, 2012 at 10:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Brendan Jurd <direvus@gmail.com> writes:
>> On 20 December 2012 11:51, Tom Lane <tgl@sss.pgh.pa.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Set visibility map bit after HOT prune
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Parser Cruft in gram.y