From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: fix for PL/PgSQL segfault |
Date: | 2003-01-16 18:47:48 |
Message-ID: | 26229.1042742868@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Neil Conway <neilc(at)samurai(dot)com> writes:
>> Then, if rec->tup is found to be NULL in RETURN NEXT, that means no
>> attempt has ever been made to assign to the variable. I'm undecided
>> about whether that case should return nulls as per your patch, or should
>> raise an error.
> It seems a little inconsistent to treat a "never-assigned-to" variable
> differently than one which has been the target of a SELECT INTO that
> returns zero rows, doesn't it?
Not entirely; the SELECT INTO is sufficient to determine the rowtype of
the variable, even if it can't stuff any data into the columns. Thus,
for example, we can allow assignment to a field of the record variable
after such a select, whereas we really can't support it when the record
variable is completely without-form-and-void. In the case of RETURN
NEXT, we are able to check that the record's rowtype matches what was
expected.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2003-01-17 18:56:39 | [Fwd: [HACKERS] Coerce to Domain] |
Previous Message | Tom Lane | 2003-01-16 18:43:29 | Re: replace oidrand() with random_sample() |