Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)

Brent Verner <brent(at)rcfile(dot)org> writes:
> more observations WRT sql that blows up postgres on Alpha.
> works:
> SELECT p.hobbies.equipment.name, p.hobbies.name, p.name
> FROM ONLY person p;
> breaks:
> SELECT p.hobbies.equipment.name, p.hobbies.name, p.name
> FROM person p;
> SELECT p.hobbies.equipment.name, p.hobbies.name, p.name
> FROM person* p;

OK, I see the problem. The breakage actually is present in 7.0.* and
prior versions as well, it just doesn't happen to be exposed by the
regress tests --- until now.

The trouble is the way that entire-tuple function arguments are handled.
Tuple types are declared in pg_type as being the same size as Oid, ie,
4 bytes. This reflects situations where a tuple value is represented by
an Oid reference to a row in a table. (I am not sure whether there is
any code left that depends on that ... in any case I'm nervous about
changing it during beta.) But the expression evaluator's implementation
of a tuple argument is that the Datum value contains a pointer to a
TupleTableSlot. This works fine as long as the Datum is just passed
around as a Datum, but if anyone tries to form a tuple containing that
Datum, only 4 bytes get stored into the tuple. Result: failure on
machines where pointers are wider than 4 bytes.

The reason this shows up in this particular regression test now, and
not before, is that 7.1 does the function evaluations at the top of
the Append plan that implements inheritance union, whereas 7.0 did it
at the bottom. That means that in 7.1, the TupleTableSlot Datum gets
inserted into a tuple that becomes part of the Append output before
it gets to the function execution. 7.0 would still show the bug
under the right circumstances --- a join would do it, for example.

I think that there may still be cases where an Oid is the correct
representation of a tuple type; anyway I'm afraid to foreclose that
possibility. What I'm thinking about doing is setting typmod of
an entire-tuple function argument to sizeof(Pointer), rather than
the default -1, to indicate that a pointer representation is being
used. Comments, hackers?

regards, tom lane