Re: help with PL/PgSQL bug
От | Gavin Sherry |
---|---|
Тема | Re: help with PL/PgSQL bug |
Дата | |
Msg-id | Pine.LNX.4.21.0301130033030.28281-100000@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: help with PL/PgSQL bug (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sat, 11 Jan 2003, Tom Lane wrote: > "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. My Oracle 8.1.7 documentation tells me that the record type is more or less like the C struct keyword. Oracle also has a concept of collections (objects). The type of these is not, however, determined on the fly. This brings up a small question: does PL/PgSQL need on the fly type casting? Gavin
В списке pgsql-hackers по дате отправления: