Re: Functions returning sets

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To:
Cc: Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Functions returning sets
Date: 2001-05-20 17:53:55
Message-ID: Pine.BSF.4.21.0105201046060.53774-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 19 May 2001, mlw wrote:

> Stephan Szabo wrote:
> >
> > (Machine couldn't find mx record for mohawksoft, replying only
> > to list)
> >
> > On Sat, 19 May 2001, mlw wrote:
> >
> > > Sorry to gripe here. Don't get me wrong, I think Postgres is amazing, and I
> > > think all you guys do an amazing job.
> > >
> > > Is it just me, or do others agree, functions returning sets need to be able to
> > > be used in a select where equal clause.
> > >
> > > select * from table where field = funct_set('bla bla');
>
> I don't understand your reasoning. Look at the syntax:
>
> select * from foo where bar = function(...);
>
> If function() returns one value, then only one will be returned and the
> relation features of postgres can be used, as in "select * from foo, this where
> foo.bar = function() and foo.bar = this.that"
>
> If function() can return multiple values, should it not follow that multiple
> values should be selected?

What does select * from foo where bar=(select value from foo2) mean when
the second returns more than one row. IIRC, sql says that's an error.
I don't see why functions returning sets would be different than a
subquery. That's what =ANY, =ALL, and IN are for. I don't see what the
difference between doing this with =s and making IN work better really is.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephan Szabo 2001-05-20 17:55:25 Re: Functions returning sets
Previous Message Tom Lane 2001-05-20 17:44:17 Re: External search engine, advice