Re: help with PL/PgSQL bug
От | Mike Mascari |
---|---|
Тема | Re: help with PL/PgSQL bug |
Дата | |
Msg-id | 003b01c2ba3c$16ee1120$0102a8c0@mascari.com обсуждение исходный текст |
Ответ на | help with PL/PgSQL bug (Neil Conway <neilc@samurai.com>) |
Список | pgsql-hackers |
----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> > "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. I searched through the Oracle 8 PL/SQL docs pretty thoroughly and couldn't find an example of a variable whose type was determinedat 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@mascari.com
В списке pgsql-hackers по дате отправления: