On Fri, 2007-10-05 at 11:42 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > 1. Why doesn't the subselect work? > > Because x = ANY (SELECT y FROM ...) is defined by the SQL standard to > involve performing x = y at each row of the SELECT output. There's > no wiggle room there. > > The standard does not specify any meaning for x = ANY (not-a-SELECT) > and we've shoehorned some array behavior into that gap, but it's > completely different semantics.
OK, so we should document it as not being possible. > > 2. Why does a function returning a polymorphic type have to have at > > least one polymorphic argument? > > So that the parser can figure out what type a particular call is > supposed to return. The parser can look at the datatype of the RETURNS clause, it doesn't need to look at the datatype of the *input* arguments. That error looks like a bug to me. In my example the input datatype differed from the returns datatype, plus the input and output were totally disconnected. => Bug. > > 3. Why is a composite type with just one attribute not the same type as > > the attribute? > > Why in the world would you expect these to be the same? It'd be akin to > claiming that a one-element array is the same as the element type. Because we already do exactly that here: select 1, (select col2 from c), 3; The inner select returns a ROW, yet we treat it as a single column value. I'll look at documenting that. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly