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 по дате отправления:

Предыдущее
От: Andreas Joseph Krogh
Дата:
Сообщение: Roadmap for 7.4
Следующее
От: Gavin Sherry
Дата:
Сообщение: Re: help with PL/PgSQL bug