From: | Marko Tiikkaja <marko(at)joh(dot)to> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns |
Date: | 2014-01-22 09:56:38 |
Message-ID: | 52DF95D6.50105@joh.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 1/22/14, 3:48 AM, Tom Lane wrote:
> Marko Tiikkaja <marko(at)joh(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-01-22 10:12:22 | Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns |
Previous Message | Dean Rasheed | 2014-01-22 07:46:29 | Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist |