Re: Functions returning sets

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Functions returning sets
Date: 2001-05-20 00:56:06
Message-ID: 3.0.1.32.20010519175606.015e2e60@mail.pacifier.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 08:44 PM 5/19/01 -0400, Tom Lane wrote:
>Don Baccus <dhogaza(at)pacifier(dot)com> writes:
>> What's so hard about writing "IN" rather than "=" ???
>
>Even more to the point, if we did adopt such a (crazy IMHO)
>interpretation of '=', what makes anyone think that it'd be
>any more efficient than IN?

I was going to mention this, but stuck to the old letter-to-the-editor
rule of one point per note. :)

>AFAICT, mlw is hoping that redefining '=' would magically avoid the
>performance problems with IN, but my bet is it'd be just the same.

Or that it would actually be a join operator??? Wasn't clear to me
exactly what he was expecting.

>What we need to do is teach the system how to handle WHERE ... IN ...
>as a form of join.

Yes.

BTW Oracle has a 1000-element limit on the number of values in an
"IN" set. This limits its generality as it applies to subselects
as well as lists of constants. It seems that PG isn't the only
RDMBS that has problems with getting "IN" implemented perfectly.

- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message mlw 2001-05-20 01:34:27 Re: Functions returning sets
Previous Message Tom Lane 2001-05-20 00:45:20 Re: Functions returning sets