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  (Gavin Sherry <swm@linuxworld.com.au>)
Список 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 по дате отправления:

Предыдущее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: v7.3.1 psql against a v7.2.x database ...
Следующее
От: Tom Lane
Дата:
Сообщение: A modest proposal for a FAQ addition