Re: fix for PL/PgSQL segfault - Mailing list pgsql-patches

From Tom Lane
Subject Re: fix for PL/PgSQL segfault
Date
Msg-id 16392.1042737538@sss.pgh.pa.us
Whole thread Raw
In response to fix for PL/PgSQL segfault  (Neil Conway <neilc@samurai.com>)
Responses Re: fix for PL/PgSQL segfault  (Neil Conway <neilc@samurai.com>)
List pgsql-patches
Neil Conway <neilc@samurai.com> writes:
> This patch fixes a segfault in the support for set-returning functions
> PL/PgSQL that occurs when an undefined RECORD variable is returned with
> RETURN NEXT. The fix is the one suggested by Tom on -hackers: a row of
> NULL values is returned.

Actually, the fix I had in mind was to cause the SELECT to assign a row
of nulls to the RECORD variable --- which is consistent with what it
will do if the SELECT target is a non-record variable.  That way, the
behavior is consistent for any subsequent use of the record variable,
not only RETURN NEXT.

Then, if rec->tup is found to be NULL in RETURN NEXT, that means no
attempt has ever been made to assign to the variable.  I'm undecided
about whether that case should return nulls as per your patch, or should
raise an error.  In the other places that access record variables, the
code seems to prefer to raise an error for a never-assigned-to record,
rather than silently substitute null.  I think we should probably try to
be consistent --- but does that mean raising an error here, or changing
those other places?  Any opinions?

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS]
Next
From: Neil Conway
Date:
Subject: backpatch minor security fixes to 7.2