Skip site navigation (1) Skip section navigation (2)

Re: Polymorphic arguments and composite types

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Polymorphic arguments and composite types
Date: 2007-10-05 17:14:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

I'll look at documenting that.

  Simon Riggs

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2007-10-05 17:18:23
Subject: Re: Release Notes Overview
Previous:From: Simon RiggsDate: 2007-10-05 17:04:54
Subject: Re: Polymorphic arguments and composite types

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group