From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: NULL and plpgsql rows |
Date: | 2006-10-03 01:21:45 |
Message-ID: | 854599F4-5F87-44D5-9CDA-DC97ECBB24C9@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Oct 2, 2006, at 6:28 PM, Tom Lane wrote:
> "Jim C. Nasby" <jim(at)nasby(dot)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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2006-10-03 01:26:51 | Re: timestamptz alias |
Previous Message | Bruce Momjian | 2006-10-03 01:18:47 | Re: [HACKERS] Bad bug in fopen() wrapper code |