Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers