| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Ken McClaren" <ken(dot)mcclaren(at)kipuhealth(dot)com> |
| Cc: | "Wetmore, Matthew (CTR)" <Matthew(dot)Wetmore(at)express-scripts(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, John Hall <john(dot)hall(at)kipuhealth(dot)com> |
| Subject: | Re: Order of operations in postgreSQL. |
| Date: | 2023-06-01 13:51:37 |
| Message-ID: | 3845.1685627497@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"Ken McClaren" <ken(dot)mcclaren(at)kipuhealth(dot)com> writes:
> Yes, the error is correct, but it should never have occurred.
> The join should have eliminated the error condition before it was evaluated by the where clause. That is the case when this type of statement is executed in SQL Server.
Postgres does not promise that JOIN conditions are evaluated before WHERE
conditions. I rather doubt that SQL Server does either, because it'd
cripple performance for a lot of real-world queries.
If you need something like that, you should restructure the query into two
levels with an optimization fence between them. One way is
SELECT ... FROM
(SELECT ... FROM t1 JOIN t2 ON join-condition OFFSET 0) ss
WHERE risky-where-condition
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ken McClaren | 2023-06-01 14:40:09 | Re: Order of operations in postgreSQL. |
| Previous Message | PG Bug reporting form | 2023-06-01 13:11:20 | BUG #17954: Postgres startup fails with `could not locate a valid checkpoint record` |