Robert Haas <robertmh...@gmail.com> writes: > The original post on this thread includes this example, which mixes > SRFs and arrays by running the array through UNNEST:
> select * from table(generate_series(10,20,5), unnest(array['fred','jim'])); > But if we think the spec calls for things to be implicitly unnested, > you could still get the same effect by adjusting the query. You'd > just get rid of the UNNEST from the argument that had it and wrap > ARRAY(SELECT ...) around the other one: > select * from table(array(select generate_series(10,20,5)), > array['fred','jim']); > It's not clear to me whether that's likely to be inefficient in > practical cases, Yeah, it would be :-(. Maybe we could hack something to translate unnest(array(...)) into a no-op, but ugh. You really want to make people use a syntax like that, even if it weren't inefficient? It's verbose, ugly, unintuitive, and redundant given that you could just write UNNEST() instead of TABLE(). But more: we *know* what the common case is going to be, based on existing usage of SRFs, and forced-unnest ain't it. So I'm thinking benign neglect of the spec's syntax is the way to go. If anyone does come along and say they want the spec's semantics, let them implement it, and the syntax to go with it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers