Re: operator dependency of commutator and negator, redux

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> a separate ALTER OPERATOR < COMMUTATOR > statement (or something of
> the sort) that pg_dump can emit as a separate item. Even a NOTICE in

I like that capability, but it's not helping us in the backward
compatibility section where we will still read commutator declarations
as operator "properties". And maintaining an extension with different
syntax for CREATE OPERATOR depending on the major version would be a
pain (it's the case already for create type by the way, painfully so).

So I think Tom's idea is better to fix the problem at hand.

About dropping the Operator Shell, we've been talking in the past about
adding more properties to our operators to allow for some more optimizer
tricks (reducing expressions to constants or straigth variable
references at parse time, reducing joins, adding parametrized paths
etc).

I can think about assiociativity and neutral element, but that's a
property of one operator only. Now there's the distributive property
that happens in between two different operators and that maybe would
better be added as an ALTER OPERATOR statement rather than a possibly
forward reference when we come to that.

I'm not too sure about other concepts that we might want to tackle down
the road here, another angle here would be about support for parallelism
where maybe operators property could tell the planner how to spread a
complex where clause or output column computation…

All in all, it looks to me like the current proposals on the table would
allow us to dispose of the Operator Shell idea entirely. If we ever need
it back, the ALTER OPERATOR trick looks like a better tool.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support