Skip site navigation (1) Skip section navigation (2)

Re: Output functions with multiple arguments considered harmful

From: elein(at)varlena(dot)com (elein)
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: elein <elein(at)varlena(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Output functions with multiple arguments considered harmful
Date: 2005-04-30 23:35:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, Apr 30, 2005 at 05:31:28PM -0400, Tom Lane wrote:
> elein(at)varlena(dot)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.


> 			regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

In response to

pgsql-hackers by date

Next:From: Mischa SandbergDate: 2005-04-30 23:41:26
Subject: OLAP and PG and deja-vu
Previous:From: James William PyeDate: 2005-04-30 23:26:30
Subject: Re: Output functions with multiple arguments considered

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group