Re: Roadmap for FE/BE protocol redesign - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Roadmap for FE/BE protocol redesign
Date
Msg-id 25229.1047689377@sss.pgh.pa.us
Whole thread Raw
In response to Re: Roadmap for FE/BE protocol redesign  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Roadmap for FE/BE protocol redesign
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Error message style guide
Next
From: Tom Lane
Date:
Subject: Re: [INTERFACES] Upgrading the backend's error-message infrastructure