Re: clearing opfuncid vs. parallel query

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? I've wondered for some time why
we don't just insist on the parser filling those nodes fully to begin
with, and get rid of the notion that assorted random places should
be expected to fix them up later. This is one of the behaviors that
would have to change to support such a simplification.

> ... The attached
> patch does by adding an "int flags" field to the relevant read
> routines.

Ick. TBH, this is just taking a bad design and putting another one
on top.

regards, tom lane