Peter Eisentraut <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
