Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2003-01-10 at 20:28, Tom Lane wrote:
>> Clearly, RETURN NEXT with an undefined record variable shouldn't dump
>> core, but what should it do? Raise an error, or perhaps be a no-op?

> I'd vote for making it a no-op. Raising an error is too severe for a
> fairly routine occurence, IMHO. If we make it a no-op, it's consistent
> with how I understand a SELECT INTO of 0 rows -- it doesn't produce an
> "undefined value", but an "empty result set" (like the difference
> between "" and a NULL pointer).

There's a consistency issue here, though.  If the SELECT INTO target
is non-record variable(s), the behavior is to set them to NULL.  Then
if you do RETURN NEXT on that, you'd emit a row full of NULLs.

It seems inconsistent that SELECT INTO a record variable produces an
undefined result rather than a row of NULLs, when there are no rows
in the SELECT result.  This would be an easy change to make, I think.
We do have a tupledesc available for the SELECT, we're just not using

Does Oracle's PL/SQL have a concept of record variables?  If so, what
do they do in this situation?

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to