Re: merge pg_proc and pg_operator?

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