On Fri, 2007-10-05 at 11:42 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> 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
