Re: operator dependency of commutator and negator
От
Tom Lane
Тема
Re: operator dependency of commutator and negator
Дата
Msg-id
15208.1285772173@sss.pgh.pa.us
Ответ на
Re: operator dependency of commutator and negator (Alvaro Herrera)
Список
Дерево обсуждения
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 по дате отправления