Boszormenyi Zoltan <z...@cybertec.at> writes:
> we have found a way to make pl/pgsql throw an error for
> a legitimate use case that works in plain SQL.
The fact that it doesn't work the way you thought doesn't make it a bug.
plpgsql expects an assignment "INTO row_variable" to be supplied from
one select column per field in the composite variable. So instead of
executing 'select (max(id),min(d))::mytype from x1', try executing
'select max(id),min(d) from x1'.
If we were to change this, we would break a lot of existing plpgsql
code; or, if we tried to support both usages, we would create nasty
semantic ambiguities for single-column composites. Possibly the
documentation in "39.5.3. Executing a Query with a Single-row Result"
could be improved though. To my eyes, it does say that this is what
happens, but it doesn't really emphasize the point that the SELECT's
output has to be "exploded" not delivered as a single composite column.
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
