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
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 |