Re: operator dependency of commutator and negator

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: operator dependency of commutator and negator
Дата
Msg-id
15208.1285772173@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
operator dependency of commutator and negator Itagaki Takahiro <itagaki.takahiro@gmail.com>
Re: operator dependency of commutator and negator Alvaro Herrera <alvherre@commandprompt.com>
Re: operator dependency of commutator and negator Tom Lane <tgl@sss.pgh.pa.us>
Re: operator dependency of commutator and negator Itagaki Takahiro <itagaki.takahiro@gmail.com>
Re: operator dependency of commutator and negator Tom Lane <tgl@sss.pgh.pa.us>
Alvaro Herrera  writes:
> Excerpts from Itagaki Takahiro's message of mié sep 29 03:56:33 -0400 2010:
>> When we drop an operator used by other operators as COMMUTATOR or NEGATOR,
>> pg_dump generates an invalid SQL command for the operators depending on
>> the dropped one. Is it an unavoidable restriction?

> Maybe we need a pg_depend entry from each pg_operator entry to the other
> one.  The problem is that this creates a cycle in the depends graph; not
> sure how well these are handled in the code, if at all.

See the comment in catalog/pg_operator.c:
   /*    * NOTE: we do not consider the operator to depend on the associated    * operators oprcom and oprnegate. We would not want to delete this    * operator if those go away, but only reset the link fields; which is not    * a function that the dependency code can presently handle.  (Something    * could perhaps be done with objectSubId though.)  For now, it's okay to    * let those links dangle if a referenced operator is removed.    */

I'm not sure that fixing this case is worth the amount of work it'd
take.  How often do you drop just one member of a commutator pair?
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Peter Eisentraut
Дата:
От: Robert Haas
Дата:
Сообщение: Re: Path question
FAQ