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

On Wed, 24 May 2023 at 16:49, Alexey Kachalin <kachalin.alexey@gmail.com> wrote:
>
> 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
bugis 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
sqlreturns 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@sss.pgh.pa.us> wrote:
>>
>> Alexey Kachalin <kachalin.alexey@gmail.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
I see the only thing to fix is to truncate output of error reported
i.e ERROR: prepared statement
"5c6b58ebdd4464734a57a87431ba24b38d2e49ae5c6b58ebdd4464734a57a87_B" to
63 symbols