Re: Polymorphic arguments and composite types

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