Re: Roadmap for FE/BE protocol redesign

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Roadmap for FE/BE protocol redesign
Дата
Msg-id 25229.1047689377@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Roadmap for FE/BE protocol redesign  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Roadmap for FE/BE protocol redesign  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> At the beginning of this thread you raised a number of points where the
> identity of the column of origin is not well-defined.  I haven't seen an
> answer to that.

Yes, Dave did answer --- basically, he's happy with not providing any
column identity data in the cases where it's not obvious what the answer
should be.  And in particular he doesn't want the mechanism to drill
down into view definitions (which is less than obviously right to me,
but if that's what he wants it sure eliminates a lot of definitional
issues).

Given that agreement I don't have a problem with providing the
functionality.  It will take a few more lines in the parser, but not an
unreasonable amount I think.

> Would you align the definition
> with what the current planner and executor structures can easily give you
> or would you use a more "mathematical" definition?  And assuming it's the
> latter, do you feel confident that that definition will not constrain
> development of the planner and executor structures in the future?

I'm not too concerned about it given the before-view-expansion proviso.
Once the rewriter and planner go into action, the contents of the query
tree do start to look rather implementation-dependent, but what the
parser does is pretty well constrained by the SQL spec.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Error message style guide
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [INTERFACES] Upgrading the backend's error-message infrastructure