Skip site navigation (1) Skip section navigation (2)

Re: operator dependency of commutator and negator

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: operator dependency of commutator and negator
Date: 2010-09-29 14:56:13
Message-ID: 15208.1285772173@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-09-29 15:01:35
Subject: Re: Path question
Previous:From: Magnus HaganderDate: 2010-09-29 14:24:03
Subject: Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group