Joe Conway <[EMAIL PROTECTED]> writes: > Good feedback -- thanks! But without the RTE, how would VALUES in the > FROM clause work?
Is it different from INSERT? I'm just imagining a Values node in the jointree and nothing in the rangetable. If I'm reading the spec correctly, VALUES is exactly parallel to SELECT in the grammar, which means that to use it in FROM you would need parentheses and an alias: SELECT ... FROM (SELECT ...) AS foo SELECT ... FROM (VALUES ...) AS foo ISTM that this should be represented using an RTE_SUBQUERY node in the outer query; the alias attaches to that node, not to the VALUES itself. So I don't think you need that alias field in the jointree entry either. If we stick with the plan of representing VALUES as if it were SELECT * FROM (valuesnode), then this approach would make the second query above have a structure like Query .rtable -> RTE_SUBQUERY .subquery -> Query .jointree -> Values (leaving out a ton of detail of course, but those are the key nodes). To get this to reverse-list in the expected form, we'd need a small kluge in ruleutils.c that short-circuits the display of "SELECT ... FROM" etc when it sees a Values node at the top of the jointree. This seems like a fairly small price to pay for keeping Query in approximately its present form, though. One thought is that we might allow Query.jointree to point to either a FromExpr or a Values node, and disallow Values from appearing further down in the jointree (except perhaps after flattening of subqueries in the planner). The alternative is that there's a FromExpr atop the Values node in the jointree even in the simple case; which seems uglier but it might avoid breaking some code that expects the top level to always be FromExpr. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match