| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | "daniel(at)sonck(dot)nl" <daniel(at)sonck(dot)nl>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | BUG #17166: PREPARE without types inconsistent type resolving |
| Date: | 2021-08-29 18:44:39 |
| Message-ID: | CAKFQuwa8k=+xYTm8s36X6EEL-HyL9_LdZx8EHN57VFxABNhDzQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Sunday, August 29, 2021, PG Bug reporting form <noreply(at)postgresql(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2021-08-30 09:02:36 | BUG #17167: UndefinedBehaviorSanitizer: invalid-shift-exponent while running int4shr/int4shl |
| Previous Message | Andrey Borodin | 2021-08-29 18:38:03 | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |