Re: merge pg_proc and pg_operator?

This thought reemerged in me during the recent discussion of the regular
expression matching operators: A lot of things could be better if
pg_proc and pg_operator were merged together.

Most importantly, operator optimization information could be attached to
procedures, so developers and users wouldn't have to make up ever more
confusing operator names, and application code would be cleaner, e.g.,

SELECT * FROM sometable WHERE somehow_intersects(a, b)

vs.

SELECT * FROM sometable WHERE a ~~@<>@~~ b;

Internally, you could delete a lot of duplicate code. In the abstract,
an operator is after all just a function call with a different syntax.
But you could just as well call

"+"(a, b)

or

a OPERATOR("add") b

Once things are out of the parser, it's all the same.

What do you think?

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> This thought reemerged in me during the recent discussion of the regular
> expression matching operators: A lot of things could be better if
> pg_proc and pg_operator were merged together.

Like what? I think this would result in a huge amount of code churn
(including lots of third-party and application-side breakage) for very
marginal benefits.

> Most importantly, operator optimization information could be attached to
> procedures,

We should definitely do that someday, but there are far less invasive
ways to do it than fundamentally restructuring core catalogs. Moreover,
the work required to make it happen is largely unrelated to the changes
you propose.

> But you could just as well call
> "+"(a, b)
> or
> a OPERATOR("add") b

I think only geeks would find that equivalence of interest. It's a
rather unintuitive dualism anyway, since you would have to explain
why the alternatives are precisely
a + b
"+"(a, b)
and why the quotes are required in the second case and forbidden in the
first case, and why the rules are quite different from that if it's a
function-ish name and not an operator-ish name.

regards, tom lane

On Sat, Jul 2, 2011 at 5:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> This thought reemerged in me during the recent discussion of the regular
>> expression matching operators: A lot of things could be better if
>> pg_proc and pg_operator were merged together.
>
> Like what?  I think this would result in a huge amount of code churn
> (including lots of third-party and application-side breakage) for very
> marginal benefits.
>
>> Most importantly, operator optimization information could be attached to
>> procedures,
>
> We should definitely do that someday, but there are far less invasive
> ways to do it than fundamentally restructuring core catalogs.  Moreover,
> the work required to make it happen is largely unrelated to the changes
> you propose.

Well, if you were to associate all of the properties that are
currently attached only to operators to functions (oprcanhash,
oprcanmerge, oprcom, etc.) then pg_operator becomes fairly pointless.
I've never liked the fact that we have a system catalog full of
functions with names like int42eq that are basically nothing but
clutter. If we could get rid of those and instead just have a bunch
of entries for =, that seems like it would be cleaner, and perhaps
even more efficient. Bloating every pg_proc row with the extra fields
that are currently only needed for operators might carry some modest
penalty, but if we're going to do that anyway for other reasons then
perhaps we may as well try to get the benefit of removing one layer of
indirection.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Jul 2, 2011 at 5:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>>> Most importantly, operator optimization information could be attached to
>>> procedures,

>> We should definitely do that someday, but there are far less invasive
>> ways to do it than fundamentally restructuring core catalogs. Moreover,
>> the work required to make it happen is largely unrelated to the changes
>> you propose.

> Well, if you were to associate all of the properties that are
> currently attached only to operators to functions (oprcanhash,
> oprcanmerge, oprcom, etc.) then pg_operator becomes fairly pointless.
> I've never liked the fact that we have a system catalog full of
> functions with names like int42eq that are basically nothing but
> clutter.

Yeah. But unless we are willing to commit wholesale breakage of
existing extensions, we need to still accommodate the idea of an
operator as a separately-created object from the underlying function.
Perhaps that could be deprecated compared to having just one catalog
entry, but it'd have to be supported. So you'd need plain functions,
standalone operators, and operators-that-are-aliases-for-functions
all floating around in the same catalog. Seems like a mess. We've
got a comparable situation now in pg_class, with entries for a number
of relkinds that users think are distinct kinds of objects, and on the
whole that hasn't been so pleasant that I'm eager to replicate the
experience elsewhere.

regards, tom lane