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

From: Julien Rouhaud <rjuju123(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
Subject: Re: Prepared SQL name collision. The name implicitly is truncated by NAMEDATALEN
Date: 2023-05-24 13:15:32
Message-ID: 20230524131532.w44kifs3bbnti6nj@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2023-05-24 13:22:37 Re: Prepared SQL name collision. The name implicitly is truncated by NAMEDATALEN
Previous Message Pavel Borisov 2023-05-24 13:02:09 Re: Prepared SQL name collision. The name implicitly is truncated by NAMEDATALEN