On Thu, 2003-01-16 at 12:18, Tom Lane wrote:
> Actually, the fix I had in mind was to cause the SELECT to assign a row
> of nulls to the RECORD variable
Heh, I just can't seem to get this patch right :-)
> 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?
In any case, I don't particularly mind which behavior we choose: when
there's a consensus, I'll send in a new version of the patch.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC