| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| Cc: | Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: possible bug in 8.4 |
| Date: | 2008-12-18 19:46:04 |
| Message-ID: | 24646.1229629564@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Yeah. NOT IN does not have the right semantics to become an antijoin.
> If we noticed that the columns in the subquery are all guaranteed to be not
> null could we do it then?
I think you'd also have to know that the outer-query value isn't null,
plus assume that the comparison operator can't return null for two
non-nulls (but we already assume that for btree/hash equality I think).
As you said, this would never have been safe before plan invalidation,
but it might be doable now.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-12-18 20:03:50 | Re: PLUGINS Functionlity in Win32 build scripts |
| Previous Message | Tom Lane | 2008-12-18 19:40:01 | Re: INSERT..SELECT with GENERATE_SERIES returns error. |