On Wed, Sep 23, 2015 at 4:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> readfuncs.c deliberately ignores any opfuncid read in for an OpExpr, >> DistinctExpr, NullIfExpr, or ScalarArrayOpExpr, instead resetting the >> value in the newly-created node to InvalidOid. This is because it >> assumes we're reading the node from a pg_node_tree column in some >> system catalog, and if in the future we wanted to allow an ALTER >> OPERATOR command to change the pg_proc mapping, then the opfuncid >> could change. We'd want to look it up again rather than using the >> previous value. > > Right, but considering that nobody has even thought about implementing > such a command in the past twenty years, maybe we should just change > the behavior of those read routines?
Well, I can't vouch for what any human being on earth has thought about over a twenty-year period. It's not intrinsically unreasonable in my mind to want to alter an operator to point at a different procedure. But if we're sure we don't want to support that, changing the behavior of the read routines would be fine with me, too. It would even save a few cycles. Would you also want to rip out the stuff that fixes up opfuncid as dead code? I assume yes, but sometimes I assume things that are false. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
