Re: help with PL/PgSQL bug
От | Tom Lane |
---|---|
Тема | Re: help with PL/PgSQL bug |
Дата | |
Msg-id | 25194.1042345347@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: help with PL/PgSQL bug ("Mike Mascari" <mascarm@mascari.com>) |
Ответы |
Re: help with PL/PgSQL bug
|
Список | pgsql-hackers |
"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. regards, tom lane
В списке pgsql-hackers по дате отправления: