From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mike Mascari" <mascarm(at)mascari(dot)com> |
Cc: | "Neil Conway" <neilc(at)samurai(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>, darcy(at)wavefire(dot)com |
Subject: | Re: help with PL/PgSQL bug |
Date: | 2003-01-12 04:22:27 |
Message-ID: | 25194.1042345347@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mike Mascari" <mascarm(at)mascari(dot)com> writes:
> From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-01-12 04:59:47 | A modest proposal for a FAQ addition |
Previous Message | Christopher Kings-Lynne | 2003-01-12 03:47:32 | Re: v7.3.1 psql against a v7.2.x database ... |