| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Alexey Kachalin <kachalin(dot)alexey(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Prepared SQL name collision. The name implicitly is truncated by NAMEDATALEN |
| Date: | 2023-05-24 13:22:37 |
| Message-ID: | CAKFQuwYO4tcnJBFTcyxs0ZGMco_L3kfuq95JyjxxF4-9qRdZXw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wednesday, May 24, 2023, Alexey Kachalin <kachalin(dot)alexey(at)gmail(dot)com>
wrote:
>
> If I exceed the limit I would like to get the error related to an issue,
> not just my valid SQL returns something unpredictable.
> Can I get a proper error for identifying issues and fixing?
> Is it expected behaviour that SQL returns corrupt value or error, when a
> prepared SQL statements name has gone beyond limit?
>
All info beyond 63 chars is discarded early on in the parsing phase.
Giving two different prepared statements the same name, as in the first 63
chars, is an application bug since, as you’ve observed, you are likely to
end up with non-deterministic behavior. Unfortunately, PostgreSQL will not
help you find this kind of bug. There presently are no plans to change
this, even though you and others would consider the lack to be undesirable.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2023-05-24 13:28:46 | BUG #17943: Undefined symbol LLVMBuildGEP in llvmjit.so during pg_restore |
| Previous Message | Julien Rouhaud | 2023-05-24 13:15:32 | Re: Prepared SQL name collision. The name implicitly is truncated by NAMEDATALEN |