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
|
Список | 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 по дате отправления: