Re: fix for PL/PgSQL segfault

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: fix for PL/PgSQL segfault
Date: 2003-01-16 17:18:58
Message-ID: 16392.1042737538@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2003-01-16 18:04:22 backpatch minor security fixes to 7.2
Previous Message mlw 2003-01-16 15:53:07 Re: