Re: help with PL/PgSQL bug

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

In response to

Responses

Browse pgsql-hackers by date

  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 ...