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

From Tom Lane
Subject Re: clearing opfuncid vs. parallel query
Date
Msg-id 21301.1443044383@sss.pgh.pa.us
Whole thread Raw
In response to Re: 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:
> 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.

Yeah, though I think of that as a longer-term issue, ie we could clean it
up sometime later.  I'm not sure right now that everyplace that initially
creates OpExpr etc. nodes is on board with having to supply opfuncid.
I do know that the main path through the parser provides 'em.  (So another
reason I don't like the current approach is that I doubt all code that
should theoretically be doing set_opfuncid() is actually doing so; it
would be too easy to miss the need for it in simple testing.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: clearing opfuncid vs. parallel query
Next
From: Stephen Frost
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!