From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Cc: | daniel(at)sonck(dot)nl |
Subject: | BUG #17166: PREPARE without types inconsistent type resolving |
Date: | 2021-08-29 18:09:17 |
Message-ID: | 17166-c3dd634fbf6f044d@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 17166
Logged by: Daniel Sonck
Email address: daniel(at)sonck(dot)nl
PostgreSQL version: 13.3
Operating system: Linux (Archlinux)
Description:
When executing the following statement, the type of $1 could not be
deduced:
SELECT * FROM my_table WHERE ($1 IS NULL OR col = $1);
However, when executing the following statement, the type of $1 could be
deduced:
SELECT * FROM my_table WHERE (col = $1 OR $1 IS NULL);
While both queries end result are the same, the first is more in line with
the meaning, saying that the optional parameter $1 may be NULL, or, if it's
not, results should be filtered by col = $1. It is rather curious that a
simple order affects the type of $1. I would imagine that, as $1 IS NULL has
no type implications, the col = $1 would determine the type of $1.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2021-08-29 18:38:03 | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |
Previous Message | Andres Freund | 2021-08-29 18:09:13 | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |