"David G. Johnston" <david.g.johns...@gmail.com> writes:
> On Tue, Sep 19, 2017 at 2:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Notice the parens/comma positioning. It's only because text is such
>> a lax datatype that you didn't notice the problem.
> I saw exactly what you described - that it didn't error out and that the
> text representation of the single output composite was being stored in the
> first field of the target composite. i.e., that it "worked". Does that
> fact that it only works if the first field of the composite type is text
> change your opinion that the behavior is OK to break?
No. That's not "working" for any useful value of "working".
I would indeed be happy if we could just change this behavior, but I do
not care to answer to the crowd of villagers that will appear if we do
that. It's just way too easy to do, eg,
declare r record;
...
for r in select lots-o-columns from ... loop ...
and then expect r to contain all the columns of the SELECT, separately.
We can't change that behavior now. (And making FOR behave differently
for this purpose than INTO wouldn't be very nice, either.)
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
