Re: NULL and plpgsql rows

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: NULL and plpgsql rows
Дата
Msg-id
16154.1159828103@sss.pgh.pa.us
Ответ на
NULL and plpgsql rows (Jim C. Nasby)
Список
Дерево обсуждения
NULL and plpgsql rows "Jim C. Nasby" <jim@nasby.net>
Re: NULL and plpgsql rows Tom Lane <tgl@sss.pgh.pa.us>
Re: NULL and plpgsql rows Jim Nasby <jim@nasby.net>
Re: NULL and plpgsql rows Bruce Momjian <bruce@momjian.us>
Re: NULL and plpgsql rows "Jim C. Nasby" <jim@nasby.net>
Re: NULL and plpgsql rows Bruce Momjian <bruce@momjian.us>
Re: NULL and plpgsql rows "Sibte Abbas" <sibtay@gmail.com>
"Jim C. Nasby"  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 allowrow_variable := int_variable;
to succeed if the int_variable chanced to contain NULL, which is surely
not very desirable.

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)?
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: AgentM
Дата:
Сообщение: Re: timestamptz alias
От: Bruce Momjian
Дата:
Сообщение: Re: Broken link in PG docs
FAQ