On Sat, Apr 30, 2005 at 05:31:28PM -0400, Tom Lane wrote: > [EMAIL PROTECTED] (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 [EMAIL PROTECTED] > ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
