From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: clearing opfuncid vs. parallel query |
Date: | 2015-09-23 21:39:43 |
Message-ID: | 21301.1443044383@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-09-23 21:40:22 | Re: No Issue Tracker - Say it Ain't So! |
Previous Message | Robert Haas | 2015-09-23 21:29:50 | Re: clearing opfuncid vs. parallel query |