Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns - Mailing list pgsql-bugs

From Marko Tiikkaja
Subject Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns
Date
Msg-id 52DF95D6.50105@joh.to
Whole thread Raw
In response to Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-bugs
On 1/22/14, 3:48 AM, Tom Lane wrote:
> Marko Tiikkaja <marko@joh.to> writes:
>>     SELECT * INTO f1, f2 FROM lotsofcolumns;
>
>> I can't say I think this is a good idea, but not sure breaking this case
>> is worth it either.
>
> Um, I thought the whole point was to complain about that.  If this isn't a
> mistake, how can you consistently maintain the other one is?

I'm sure you can see a difference between explicitly listing the wrong
number of columns and using * to ignore trailing columns.  That said,
this *should* be an error according to the documentation, so it's
probably not the end of the world if we break it.

>> In bug #8893 there was some discussion which I interpreted to mean that
>> we could improve this a bit by checking the number of returned columns
>> during compile time if there's no * in the target list.  Attached is a
>> crude patch attempting to do that, which appears to be working.  Any
>> thoughts?
>
> Ick.  I thought you wanted to do this at first execution, anyway, not in
> pl_gram.y.

Catching these errors at compile time would be ideal.  If we also want
to catch the * cases we could also check the result structure before the
first execution.


Regards,
Marko Tiikkaja

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns
Next
From: Pavel Stehule
Date:
Subject: Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns