Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Jul 2, 2011 at 5:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Peter Eisentraut <peter_e@gmx.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
