On Mon, May 18, 2015 at 5:44 PM, Uriy Zhuravlev <u.zhurav...@postgrespro.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
