On Sat, Apr 30, 2005 at 05:31:28PM -0400, Tom Lane wrote:
> 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.
I agree with you. Now we just need to be able to cast unnamed row types
in SQL and/or access elements of unnamed row types somehow.
--elein
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>