Re: NULL and plpgsql rows

Поиск
Список
Период
Сортировка
От Sibte Abbas
Тема Re: NULL and plpgsql rows
Дата
Msg-id bd6a35510710201155v293fdf49pd455703a74ab52f1@mail.gmail.com
обсуждение исходный текст
Ответ на Re: NULL and plpgsql rows  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 10/2/06, Tom Lane <tgl@sss.pgh.pa.us> 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.
>
> 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)?
>

Is there a specific reason why we keep the tuple descriptor of an
unassigned record type to NULL?

Surely we don't know what tuple descriptor it will actually contain,
however, maybe we can have "special" tuple descriptors for un-assigned
record types.

For example, if for NULL/unassigned record type we create a tuple
descriptor of "VOID" type, and then initialize its corresponding (one
column) row to null, we 'll have the <row> IS NULL check working on
unassigned or NULL record types as well.

regards,
-- 
Sibte Abbas


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

Предыдущее
От: "Luke Lonergan"
Дата:
Сообщение: Re: Including Snapshot Info with Indexes
Следующее
От: Tom Lane
Дата:
Сообщение: Poorly designed tsearch NOTICEs