Re: Prepared SQL name collision. The name implicitly is truncated by NAMEDATALEN - Mailing list pgsql-bugs

From Julien Rouhaud
Subject Re: Prepared SQL name collision. The name implicitly is truncated by NAMEDATALEN
Date
Msg-id 20230524131532.w44kifs3bbnti6nj@jrouhaud
Whole thread Raw
In response to Re: Prepared SQL name collision. The name implicitly is truncated by NAMEDATALEN  (Alexey Kachalin <kachalin.alexey@gmail.com>)
List pgsql-bugs
Hi,

Please don't top post on this list.

On Wed, May 24, 2023 at 12:40:26PM +0100, Alexey Kachalin wrote:
> 
> 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?

Unless I'm missing something your scenario did raise an error, you just
apparently ignored it and continued, and then eventually got wrong results:

rjuju=# PREPARE aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffggg AS
(SELECT 1);
PREPARE

rjuju=# PREPARE aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggg AS
(SELECT 2);
NOTICE:  42622: identifier "aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggg" will be truncated to
"aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffggg"
ERROR:  42P05: prepared statement "aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffggg" already exists

You should have stopped execution here, or at least tried to do something.

You simply can't expect to execute a prepared statements that you haven't
successfully prepared.  The notice does gives you a clue of why it could have
failed, but it could have been something else too.

rjuju=# EXECUTE aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggg;
NOTICE:  42622: identifier "aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggg" will be truncated to
"aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffggg"

 ?column?
----------
        1
(1 row)

The fact that this execution returned the wrong result rather than error out
isn't really different from say a bug on your code that generates duplicated
names that don't get truncated.  You shouldn't have tried to execute it.



pgsql-bugs by date:

Previous
From: Pavel Borisov
Date:
Subject: Re: Prepared SQL name collision. The name implicitly is truncated by NAMEDATALEN
Next
From: "David G. Johnston"
Date:
Subject: Re: Prepared SQL name collision. The name implicitly is truncated by NAMEDATALEN