Re: clearing opfuncid vs. parallel query - Mailing list pgsql-hackers

From Tom Lane
Subject Re: clearing opfuncid vs. parallel query
Date
Msg-id 19703.1443040305@sss.pgh.pa.us
Whole thread Raw
In response to clearing opfuncid vs. parallel query  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: clearing opfuncid vs. parallel query  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@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?  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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!
Next
From: Jim Nasby
Date:
Subject: Re: Less than ideal error reporting in pg_stat_statements