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

On Tue, Nov 9, 2010 at 12:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "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.

In cases where both the field layout and the field of interest are
known at plan time this not violating the static principles of
plpgsql. Suppose we decided to access field by name via
recordvar{name} or recordvar{field pos}:

DECLARE
r record;
f foo;
t text default 'id';
BEGIN
<some code>
r{'id'} = 5; -- no good, r is dynamic record
f{t} 5; -- no good, t is not immutable
f{'id'} = 5; -- ok;

Iterating over fields of type foo is not interesting because fields
are already known to whoever is writing the function, and flatten to
text cases are already covered. IOW, the above syntax is not really
useful because you can just do:
f.id = 5;

The only exception I see is in trigger functions. If the trigger
function plan is specific to the firing trigger, new and old are
defined at plan time, so something like:

new{TG_FIELDNAMES[1]} = 5; -- is ok (at least IMO), since
TG_FIELDNAMES is immutable (at least to the plan).

I don't honestly know if it's worth it -- the main case is performance
(plus Pavel's secondary argument of loss of type information).
Something like this would address an awful lot of gripes about trigger
functions though.

merlin