Robert Haas <robertmhaas@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
