Re: Polymorphic arguments and composite types - Mailing list pgsql-hackers

From Stephan Szabo
Subject Re: Polymorphic arguments and composite types
Date
Msg-id 20071005111655.N13527@megazone.bigpanda.com
Whole thread Raw
In response to Re: Polymorphic arguments and composite types  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Polymorphic arguments and composite types
List pgsql-hackers
On Fri, 5 Oct 2007, Simon Riggs wrote:

> On Fri, 2007-10-05 at 10:59 -0700, Stephan Szabo wrote:
> > On Fri, 5 Oct 2007, Simon Riggs wrote:
> >
> > > On Fri, 2007-10-05 at 10:32 -0700, Stephan Szabo wrote:
> > > > On Fri, 5 Oct 2007, Simon Riggs wrote:
> > > >
> > > > > 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.
> > > >
> > > > The inner select does not return a row. It's not a <row subquery>, it's a
> > > > <scalar subquery>.
> > >
> > > Thanks Stephan, Tom already explained that.
> > >
> > > My comments above were in response to "Why would you think that?"
> >
> > Right, but I guess I couldn't see why you would consider that the same as
> > treating a rowtype as a scalar, because when I look at that my brain
> > converts that to a scalar subquery, so I guess I simply see the scalar.
> > If we supported select 1, (select 2,3), select 4 giving something like
> > (1,(2,3),4), I'd also have confusion over the case, but that should error.
>
> Well, my brain didn't... All I've said was that we should document it,
> to help those people that don't know they're SQL standard as good as the
> best people on this list.

Where would you document this beyond 4.2 though? While I don't exactly
like the wording of 4.2.9, it seems like it's already trying to say that.


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Polymorphic arguments and composite types
Next
From: Simon Riggs
Date:
Subject: Re: Polymorphic arguments and composite types