Re: NULL and plpgsql rows - Mailing list pgsql-hackers

From Sibte Abbas
Subject Re: NULL and plpgsql rows
Date
Msg-id bd6a35510710201155v293fdf49pd455703a74ab52f1@mail.gmail.com
Whole thread Raw
In response to Re: NULL and plpgsql rows  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: "Luke Lonergan"
Date:
Subject: Re: Including Snapshot Info with Indexes
Next
From: Tom Lane
Date:
Subject: Poorly designed tsearch NOTICEs