Joe Conway <mail@joeconway.com> 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
