From: | "Mike Mascari" <mascarm(at)mascari(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 13:11:16 |
Message-ID: | 003b01c2ba3c$16ee1120$0102a8c0@mascari.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> "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.
I searched through the Oracle 8 PL/SQL docs pretty thoroughly and couldn't find an example of a variable whose type was determined at run-time. Maybe the pgPL/SQL RECORD implementor can shed some more light on the issue, but as far as I can tell, Oracle's PL/SQL is strongly typed.
Mike Mascari
mascarm(at)mascari(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Sherry | 2003-01-12 13:35:14 | Re: help with PL/PgSQL bug |
Previous Message | Andreas Joseph Krogh | 2003-01-12 12:28:10 | Roadmap for 7.4 |