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

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

Reply via email to