Re: fix for PL/PgSQL segfault

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

In response to

Browse pgsql-patches by date

  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()