Re: Values list-of-targetlists patch for comments (was Re: [PATCHES] [HACKERS] 8.2 features?)
Gavin Sherry <[EMAIL PROTECTED]> writes: > Is this intentional: > template1=# values(1), (2); > column1 > - >1 >2 > (2 rows) You bet. VALUES is parallel to SELECT in the SQL grammar, so AFAICS it should be legal anywhere you can write SELECT. The basic productions in the spec's grammar are respectively ::= SELECT [ ] and ::= VALUES and both of them link into the rest of the grammar here: ::= | | There is no construct I can find in the spec grammar that allows but not . QED. Try some stuff like DECLARE c CURSOR FOR VALUES ... WHERE foo IN (VALUES ... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Values list-of-targetlists patch for comments (was Re: [PATCHES] [HACKERS] 8.2 features?)
Here's what I've got so far. I think there's probably more gold to be mined in terms of reducing runtime memory consumption (I don't like the list_free_deep bit, we should use a context), but functionally it seems complete. I'm off to dinner again, it's in your court to look over some more if you want. (PS: if you want to apply, go ahead, don't forget catversion bump.) regards, tom lane binYX6JKaCeEm.bin Description: values-lists-1.patch.gz ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: Values list-of-targetlists patch for comments (was Re: [PATCHES] [HACKERS] 8.2 features?)
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
Re: Values list-of-targetlists patch for comments (was Re: [PATCHES] [HACKERS] 8.2 features?)
Joe Conway <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> There are basically two ways you could go about this: >> 1. Make a new jointree leaf node type to represent a VALUES construct, >> and dangle the list of lists of expressions off that. >> 2. Make a new RangeTblEntry type to represent a VALUES construct, and >> just put a RangeTblRef to it into the jointree. The expressions >> dangle off the RangeTblEntry. You seem to have done *both*, which is certainly not what I had in mind. I'd drop the RangeTblEntry changes, I think. Shoving all the tuples into a tuplestore is not doing anything for you from a performance point of view. I was thinking more of evaluating the targetlists on-the-fly. Basically what I foresaw as the executor mechanism was something like a Result node, except with a list of targetlists instead of just one, and part of its runtime state would be an index saying which one to evaluate next. (The update logic for the index would be just like Append's logic for which subplan to eval next.) Result as it currently stands is a pretty queer beast because it can have a child plan or not. I'm tempted to suggest splitting it into two node types, perhaps call the one with a child "Filter" and reserve the name "Result" for the one with no child. The reason for doing this in this context is that we could just make the no-child case be multi-targetlist-capable (rather than having separate nearly identical node types with single and multi tlists). AFAICS multi tlists don't make any sense for the filter-a-child-plan scenario, so that's why I want to push that case off to a different node type. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
