From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Pulling up more complicated subqueries |
Date: | 2017-05-17 16:30:46 |
Message-ID: | CA+Tgmob-qY_NYGYQODiwFgnhqKKusLJT=99QHDO5C2n-y1MLdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 17, 2017 at 11:08 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> That's not a straight semi-join, but we could still turn it into a new kind
> of LEFT-SEMI join. A left-semi join is like a left join, in that it returns
> all rows from the left side, and NULLs for any non-matches. And like a
> semi-join, it returns only one matching row from the right-side, if there
> are duplicates. In the qual, replace the SubLink with an IS NOT NULL test.
...
> This can be implemented using yet another new join type, a LEFT-UNIQUE join.
> It's like a LEFT JOIN, but it must check that there are no duplicates in the
> right-hand-side, and throw an error if there are (ERROR: more than one row
> returned by a subquery used as an expression).
It seems like we might want to split what is currently called JoinType
into two separate things -- one that is INNER/LEFT/RIGHT/FULL and the
other that says what to do about multiple matches, which could be that
they are expected, they are to be ignored (as in your LEFT-SEMI case),
or they should error out (as in your LEFT-UNIQUE case).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Remi Colinet | 2017-05-17 16:31:15 | Re: [PATCH v2] Progress command to monitor progression of long running SQL queries |
Previous Message | Robert Haas | 2017-05-17 16:24:01 | Re: pgsql: Tag refs/tags/REL_10_BETA1 was created |