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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>
Subject: Re: proposal: plpgsql - iteration over fields of rec or row variable
Date: 2010-11-09 17:34:37
Message-ID: 23975.1289324077@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David E. Wheeler" <david(at)kineticode(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-11-09 17:35:10 Re: proposal: plpgsql - iteration over fields of rec or row variable
Previous Message Greg Stark 2010-11-09 17:31:01 Re: Protecting against unexpected zero-pages: proposal