Re: proposal: plpgsql - iteration over fields of rec or row variable
От | Pavel Stehule |
---|---|
Тема | Re: proposal: plpgsql - iteration over fields of rec or row variable |
Дата | |
Msg-id | AANLkTimhgf3hZBs92PMtNyv3cXrngEszhczXxTbx8od8@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: plpgsql - iteration over fields of rec or row variable (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2010/11/9 Tom Lane <tgl@sss.pgh.pa.us>: > "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. yes - I know these arguments well. But you have to know so any combination of PL increase a project complexity and increase a price for maintaining, installation, Now It's relative safe to say to somebody - you need a plpgsql. But it's more difficult to say same about plperl, pltcl, plpython - I like plperl too much, but I would to use it for untrusted operation and not for some very simple and general task. Pavel > > regards, tom lane >
В списке pgsql-hackers по дате отправления: