Обсуждение: BUG #17166: PREPARE without types inconsistent type resolving

Поиск
Список
Период
Сортировка

BUG #17166: PREPARE without types inconsistent type resolving

От
PG Bug reporting form
Дата:
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.


BUG #17166: PREPARE without types inconsistent type resolving

От
"David G. Johnston"
Дата:
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.