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 15:04:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, 2007-10-05 at 10:52 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > ...which is fine on just one table, but I want to join...
> > postgres=# select * from c where col1 = any (select col2 from c);
> > ERROR:  operator does not exist: integer = integer[]
> That isn't a join.  Are you looking for something like

I guess I was looking for the sub-select way of doing it, because I
actually wanted to exclude rows.

> select * from c, c as c2 where c.col1 = any (c2.col2)

That works, thanks. 

As I said, I already solved the problem a different way. I was looking
to understand the 3 questions I raised along the way.

Can you throw any light on those questions?
1. Why doesn't the subselect work?

2. Why does a function returning a polymorphic type have to have at
least one polymorphic argument? It's easy to create a function that
returns a polymorphic result yet has no linkage at all to the input.

3. Why is a composite type with just one attribute not the same type as
the attribute? We know this is possible in the SELECT list, but we don't
know its the same thing in other contexts.

  Simon Riggs

In response to


pgsql-hackers by date

Next:From: Oleg BartunovDate: 2007-10-05 15:31:34
Subject: Re: default_text_search_config
Previous:From: Tom LaneDate: 2007-10-05 15:03:04
Subject: Re: default_text_search_config

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