Re: fix for PL/PgSQL segfault

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: fix for PL/PgSQL segfault
Дата
Msg-id 16392.1042737538@sss.pgh.pa.us
обсуждение исходный текст
Ответ на fix for PL/PgSQL segfault  (Neil Conway <neilc@samurai.com>)
Ответы Re: fix for PL/PgSQL segfault  (Neil Conway <neilc@samurai.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS]
Следующее
От: Neil Conway
Дата:
Сообщение: backpatch minor security fixes to 7.2