BUG #17166: PREPARE without types inconsistent type resolving

Started by PG Bug reporting formover 4 years ago2 messagesbugs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following bug has been logged on the website:

Bug reference: 17166
Logged by: Daniel Sonck
Email address: daniel@sonck.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.

#2David G. Johnston
david.g.johnston@gmail.com
In reply to: PG Bug reporting form (#1)

On Sunday, August 29, 2021, PG Bug reporting form <noreply@postgresql.org>
wrote:

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.

The system resolves the type of each argument at its first encounter while
parsing. It has to make a choice, and since “is null” doesn’t provide any
help, it is unable to make a decision. Null “values” are still typed.

This is documented under the PREPARE SQL command reference (the only pure
sql way to use numbered parameters) and so is definitely not a bug.

David J.