On 10/19/15 7:12 PM, Tom Lane wrote:
> 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.)
That also means there would only need to be changes to RECORD to allow
CONSTANT, default, etc.
Do you know offhand what the starting point for changing that would be?
build_datatype()?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com