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
|
Список | 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 по дате отправления: