Re: NULL and plpgsql rows

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: NULL and plpgsql rows
Дата
Msg-id 854599F4-5F87-44D5-9CDA-DC97ECBB24C9@nasby.net
обсуждение исходный текст
Ответ на Re: NULL and plpgsql rows  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: NULL and plpgsql rows  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Oct 2, 2006, at 6:28 PM, Tom Lane wrote:
> "Jim C. Nasby" <jim@nasby.net> writes:
>> However, the test right above that means that we'll fail if the user
>> tries something like "row_variable := NULL;":
>
> The patch you seem to have in mind would allow
>     row_variable := int_variable;
> to succeed if the int_variable chanced to contain NULL, which is  
> surely
> not very desirable.

Hrm... is there any reasonable way to catch that?

> The real issue here is that the bare NULL has type UNKNOWN and  
> we're not
> making any effort to cast it.  I'm not sure whether it'd work to  
> simply
> apply exec_cast_value --- that looks like it's only meant to handle
> scalars, where in general you'd need something close to
> ExecEvalConvertRowtype().
>
>> Of course, setting a row variable to null is a lot more useful if  
>> we can
>> actually test for it after the fact, and I'm not really sure how  
>> to make
>> that happen.
>
> Doesn't IS NULL work (as of CVS HEAD)?

Ahh, so it does. Doesn't work with RECORD, though... which seems a  
bit surprising. I can't really think of a good reason why they should  
differ.

ERROR:  record "v_row" is not assigned yet
DETAIL:  The tuple structure of a not-yet-assigned record is  
indeterminate.
CONTEXT:  PL/pgSQL function "test" line 4 at return

--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] Bad bug in fopen() wrapper code
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: timestamptz alias