elein@varlena.com (elein) writes:
> On Sat, Apr 30, 2005 at 04:17:59PM -0400, Tom Lane wrote:
>> It is trivial to crash 8.0's record_out
>> by lying to it about the rowtype of its first argument.
> Is it not as trivial to crash it if one passes bad data into it?
> Why is the oid arg worse than the data arg?
The first argument is presumably valid in itself (if not, you've got
worse problems than this). The problem is that record_out was coded
to believe the second argument correctly gives the rowtype of the
first, so it could be induced to try to interpret the tuple using the
wrong tuple descriptor. I've not bothered to try to construct an
actual crash scenario, but I'm sure Bad Things are possible.
The whole thing is unnecessary anyway, because in the system as-released
every composite Datum is guaranteed to carry internal type labeling;
record_out should simply rely on that always, rather than believing a
type OID that comes from someplace else.
> Theoretically any time can be a super type which does complicate things.
Not really. Every rowtype Datum will carry its own concrete type.
> I believe the generic types' output functions need to be able to be
> told what sort of thingy they are expecting to be.
That's exactly the thinking I think we need to get away from. What I'm
really after here is enforcing the viewpoint that instances of generic
types (such as arrays and rows) have to be self-identifying as to just
which subtype they are. If the info comes from outside the object
itself, it's unreliable. We have already found ourselves forced to
adopt this position with respect to arrays and records, so I'm thinking
we want to make sure we don't make the same mistake yet again.
regards, tom lane
