Re: WIP: Enhanced ALTER OPERATOR

On Mon, May 18, 2015 at 5:44 PM, Uriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>
wrote:

> On Monday 18 May 2015 10:21:10 Tom Lane wrote:
> > There are fairly significant reasons why we have not done this, based
> > on the difficulty of updating existing cached plans that might have
> > incidentally depended on those operator properties during creation.
> > Perhaps it's all right to simply ignore such concerns, but I would like
> > to see a defense of why.
>
> Then need to prohibit the use of shells operators (stub operators) to
> create
> self-linkage. Implicitly changing commutators and negators working for a
> long
> time through the shell operators.
>

I could give another motivation. AFAICS, typically ALTER OPERATOR should
introduce enchancements. For instance, some version of extension didn't
have negator for operator. In the next version extension introduce such
negator. Or the same situation with selectivity estimation. If ALTER
OPERATOR introduce only enchancements then old plans could be not optimal
but they don't lead to invalid query answers. From this point of view cache
invalidation after ALTER OPERATOR is term of optimization. We could include
into the patch documentation statement about possible side effects with
cached query plans.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company