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

Hello, Tom and other devs.

I would like to point out that this bug report is not about trucating
identifiers as mentioned in documentation. The bug is collision, neither
trucating.

This is about getting different SQL errors on valid SQL statements.
The valid SQL produces an error, it is a bug, isn't it?
If a programmer did something wrong the error appears, I believe in that.

Please consider an example:
Run
'SELECT 222 as result_1'
and get the result of '111' because of a collision.
How should programmers understand the prepared SQL name exceeding length?
No error, no warning, nothing, just valid sql returns the wrong result.

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?

On Tue, May 23, 2023 at 3:07 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alexey Kachalin <kachalin(dot)alexey(at)gmail(dot)com> writes:
> > Prepared SQL name collision. The name implicitly is truncated by
> > NAMEDATALEN
>
> This is not a bug. You exceeded a well-documented implementation
> limit, and the response is as documented.
>
> > Is it possible to know which value was used at compilation time from
> > application code?
>
> You can do
>
> =# show max_identifier_length;
> max_identifier_length
> -----------------------
> 63
> (1 row)
>
> or various equivalent ways of inspecting that parameter.
>
> regards, tom lane
>