On 08/21/2014 02:09 PM, Marko Tiikkaja wrote:
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
Ok.
(and also, unfortunately, I'm on vacation right now).
Oh, have fun!
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.
Hmm. The integer FOR syntax I used in my example does not, it always
expects 1 output column.
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.
You might want to add a helper function to count the number of
attributes in a PLpgSQL_row. Then the check_sql_expr call would be
almost as simple: check_sql_expr(..., get_row_natts(row)).
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
