Re: help with PL/PgSQL bug - Mailing list pgsql-hackers

From Tom Lane
Subject Re: help with PL/PgSQL bug
Date
Msg-id 25194.1042345347@sss.pgh.pa.us
Whole thread Raw
In response to Re: help with PL/PgSQL bug  ("Mike Mascari" <mascarm@mascari.com>)
Responses Re: help with PL/PgSQL bug  (Gavin Sherry <swm@linuxworld.com.au>)
List pgsql-hackers
"Mike Mascari" <mascarm@mascari.com> writes:
> From: "Tom Lane" <tgl@sss.pgh.pa.us>
>> That's a rowtype variable, though, not a record variable.  I believe our
>> code will work the same as Oracle for that case.

>   4  TYPE EmpRec IS RECORD (
>   5   id NUMBER,
>   6   name VARCHAR(20)
>   7  );
>   8  emp_rec EmpRec;

> behaves similarly by returning a NULL value for an unmatched row.

Hm, that's interesting --- does Oracle not think that "record" means
what our plpgsql think it means?  I thought we'd stolen all those
semantics straight from Oracle.

In plpgsql, you can declare a variable like so:foo RECORD;
and that means that it's an unspecified rowtype, whose fields will be
determined on-the-fly to match the query that assigns to it.  It's this
case that I'm concerned about, because right now it behaves differently
from the case where the variable's rowtype is predetermined.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: v7.3.1 psql against a v7.2.x database ...
Next
From: Tom Lane
Date:
Subject: A modest proposal for a FAQ addition