On 8/21/14, 1:19 PM, Heikki Linnakangas wrote:
> On 08/07/2014 01:11 AM, Marko Tiikkaja wrote:
>> On 7/21/14, 10:56 PM, I wrote:
>>> Here's a patch which allows you to notice those annoying bugs with INTO
>>> slightly more quickly. Adding to the next commit phest.
>>
>> New version, fixed bugs with set operations and VALUES lists.
>
> Looks good.
>
> There's probably more checking like that that you could add, but that
> can be done as add-on patches, if ever. The INTO mistake happens a lot
> more easily.
Yeah, I think the mistake is at least as easy to do in "FOR .. IN
<query>", and I'm planning to add checks for that as well. But I
haven't found the time to look at it amongst all the other patches and
projects I have going (and also, unfortunately, I'm on vacation right now).
> It seems weird to pass a PLpgSQL_row struct to check_sql_expr.
> check_sql_expr only needs to know how many attributes is expected to be
> in the target list, so it would be more natural to just pass an "int
> expected_natts".
I'm not sure about this, though. AFAICT all the interesting cases are
already holding a PLpgSQL_row, and in that case it seems easier to just
pass that in to check_sql_expr() without making the callers worry about
extracting the expected_natts from the row. And we can always change
the interface should such a case come up, since the interface is
completely internal. Just my 0.02EUR, of course.
.marko
