Re: proposal: plpgsql - iteration over fields of rec or row variable

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: proposal: plpgsql - iteration over fields of rec or row variable
Дата
Msg-id 23975.1289324077@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: proposal: plpgsql - iteration over fields of rec or row variable  ("David E. Wheeler" <david@kineticode.com>)
Ответы Re: proposal: plpgsql - iteration over fields of rec or row variable  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: proposal: plpgsql - iteration over fields of rec or row variable  ("David E. Wheeler" <david@kineticode.com>)
Re: proposal: plpgsql - iteration over fields of rec or row variable  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-hackers
"David E. Wheeler" <david@kineticode.com> writes:
> You realize you can pretty much do all this with hstore, right?

Yeah.  Anything that involves smashing all the fields to text is not
really an advance over (a) hstore or (b) using plperl or one of the
other weakly-typed PLs.

I think there's a fairly fundamental contradiction involved here.
One of the basic design attributes of plpgsql is that it's strongly
typed.  Sometimes that's a blessing, and sometimes it's not, but
it's a fact.  There really isn't a good way to deal with run-time
field selection while still maintaining strong typing.  I do not
believe that the answer to that problem is "so let's break strong
typing".  Rather, the answer is that if that's what you need, you
need to use a different tool.  There's a reason we support multiple
PLs.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Protecting against unexpected zero-pages: proposal
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: plpgsql - iteration over fields of rec or row variable