| 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: | Whole Thread | Raw Message | 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() |