Re: Prepared SQL name collision. The name implicitly is truncated by NAMEDATALEN

Thank you for the clarification.

The "bug" report may be closed.

On Wed, May 24, 2023 at 2:22 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> 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.
>
>