Thread: 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@gmx.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 preciselya + 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@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.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@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