Andres Freund <and...@anarazel.de> writes: > On 2016-09-12 12:10:01 -0400, Tom Lane wrote: >> I can't say that I like the proposed syntax much.
> Me neither. But I haven't really found a better approach. It seems > kinda consistent to have ROWS FROM (... AS ()) change the picked out > columns to 0, and just return the whole thing. I just remembered that we allow zero-column composite types, which makes this proposal formally ambiguous. So we really need a different syntax. I'm not especially in love with the cast-to-record idea, but it does dodge that problem. Stepping back a little bit ... way back at the start of this thread you muttered about possibly implementing tSRFs as a special pipeline node type, a la Result. That would have the same benefits in terms of being able to take SRF support out of the main execQual code paths. I, and I think some other people, felt that the LATERAL approach would be a cleaner answer --- but now that we're seeing some of the messy details required to make the LATERAL way work, I'm beginning to have second thoughts. I wonder if we should do at least a POC implementation of the other way to get a better fix on which way is really cleaner. Also, one of the points that's come up repeatedly in these discussions is the way that the parser's implementation of *-expansion sucks for composite-returning functions. That is, if you write SELECT (foo(...)).* FROM ... you get SELECT (foo(...)).col1, (foo(...)).col2, ... FROM ... so that the function is executed N times not once. We had discussed fixing that for setof-composite-returning functions by folding multiple identical SRF calls into a single LATERAL entry, but that doesn't directly fix the problem for non-SRF composite functions. Also the whole idea of having the planner undo the parser's damage in this way is kinda grotty, not least because we can't safely combine multiple calls of volatile functions, so it only works for not-volatile ones. That line of thought leads to the idea that if we could have the *parser* do the transformation to LATERAL form, we could avoid breaking a composite-returning function call into multiple copies in the first place. I had said that I didn't think we wanted this transformation done in the parser, but maybe this is a sufficient reason to do so. If we think in terms of pipeline evaluation nodes rather than LATERAL, we could implement the above by having the parser emit multiple levels of SELECT some-expressions FROM (SELECT some-expressions FROM ...), with SRFs being rigidly separated into their own evaluation levels. I'm not certain that any of these ideas are worth the electrons they're written on, but I do think we ought to consider alternatives and not just push forward with committing a first-draft implementation. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers