pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17166: PREPARE without types inconsistent type resolving
2+ messages / 2 participants
[nested] [flat]
* BUG #17166: PREPARE without types inconsistent type resolving
@ 2021-08-29 18:09 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 2+ messages in thread
From: PG Bug reporting form @ 2021-08-29 18:09 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: daniel@sonck.nl
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.
^ permalink raw reply [nested|flat] 2+ messages in thread
* BUG #17166: PREPARE without types inconsistent type resolving
@ 2021-08-29 18:44 David G. Johnston <david.g.johnston@gmail.com>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 0 replies; 2+ messages in thread
From: David G. Johnston @ 2021-08-29 18:44 UTC (permalink / raw)
To: daniel@sonck.nl <daniel@sonck.nl>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
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.
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2021-08-29 18:44 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-08-29 18:09 BUG #17166: PREPARE without types inconsistent type resolving PG Bug reporting form <noreply@postgresql.org>
2021-08-29 18:44 ` David G. Johnston <david.g.johnston@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox