Re: clearing opfuncid vs. parallel query

On Wed, Sep 23, 2015 at 4:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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