Re: clearing opfuncid vs. parallel query

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: clearing opfuncid vs. parallel query
Дата
Msg-id 21301.1443044383@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: clearing opfuncid vs. parallel query  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: clearing opfuncid vs. parallel query  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: clearing opfuncid vs. parallel query
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: No Issue Tracker - Say it Ain't So!