Jim Nasby <Jim.Nasby@bluetreble.com> writes:
> What did seem odd is that while processing the DECLARE section there
> were plpgsql datums for tt.a and tt.b. I would have expected the
> assignment to produce a row datum of type tt.
Yeah, that's the thing that's weird about plpgsql's ROW datums.
What the row datum mechanism is actually good for IMO is representing
multiple targets for FOR and INTO constructs, ie SELECT ... INTO a,b,c;
If you look at the representation of INTO, it only allows one target
datum, and the reason that's OK is it uses a row datum for cases like
this. The row member datums are just the scalar variables a,b,c,
which can also be accessed directly.
IMO, we ought to get rid of the use of that representation for
composite-type variables and use the RECORD code paths for them,
whether they are declared as type record or as named composite
types. That would probably make it easier to handle this case,
and it'd definitely make it easier to deal with some other weak
spots like ALTER TYPE changes to composite types. However, last
time I proposed that, it was shot down on the grounds that it might
hurt performance in some cases. (Which is likely true, although
that argument ignores the fact that other cases might get better.)
regards, tom lane
