Re: Order of operations in postgreSQL. - Mailing list pgsql-bugs

Thanks for your help.

This was a bad assumption on my part. I did not know that Postgres did not make that promise.

 

 

Ken McClaren Database Administrator   864.313.5997 Easley, SC Instagram | LinkedIn | Facebook | Twitter kipuhealth.com

 

 

 

 

From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thursday, June 1, 2023 at 9:51 AM
To: Ken McClaren <ken.mcclaren@kipuhealth.com>
Cc: Wetmore, Matthew (CTR) <Matthew.Wetmore@express-scripts.com>, pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>, John Hall <john.hall@kipuhealth.com>
Subject: Re: Order of operations in postgreSQL.

[You don't often get email from tgl@sss.pgh.pa.us. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

"Ken  McClaren" <ken.mcclaren@kipuhealth.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