Re: BUG #13659: Constraint names truncated without error

From: James Coleman <jtc331(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #13659: Constraint names truncated without error
Date: 2015-10-01 17:40:09
Message-ID: CAAaqYe-DhJDRHUCABM0En59Kr+PX1dg6RDosUHHXaZYZMzSgTA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I did some more testing, and at least one of the cases I found out that the
tool I was using to execute the DDL was intercepting some of the length
issues and not others.

I was pretty confident that I had encountered an issue with raw SQL as
well, but I just put together an test case with indexes, functions, foreign
keys, etc. and couldn't find an issue. My apologies for submitting
incorrect information in that regard.

Perhaps what I'd encountered was the fact that a truncated function name
means you can accidentally run into a "function already exists with name"
error unintentionally.

Has there ever been any discussion about making truncation an error level
message rather than a notice?

On Thu, Oct 1, 2015 at 11:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> jtc331(at)gmail(dot)com writes:
> > If I create the following schema:
>
> > create table t(n integer);
> > alter table t add constraint
> >
> test_contrainst_that_has_a_very_long_name_to_trigger_the_character_limit
> > check (n != 1);
>
> > the constraint name appears to be automatically truncated without error,
> as
> > confirmed with:
>
> > SELECT tc.constraint_name, tc.table_name
> > FROM information_schema.table_constraints AS tc
> > WHERE tc.table_name = 't'
>
> > Since PG raises errors when index names, for example, are too long, I
> > believe it should do the same for constraints.
>
> Really? I see the same type of behavior for both cases:
>
> regression=# create table t(n integer);
> CREATE TABLE
> regression=# alter table t add constraint
> test_contrainst_that_has_a_very_long_name_to_trigger_the_character_limit
> check (n != 1);
> NOTICE: identifier
> "test_contrainst_that_has_a_very_long_name_to_trigger_the_character_limit"
> will be truncated to
> "test_contrainst_that_has_a_very_long_name_to_trigger_the_charac"
> ALTER TABLE
> regression=# create index
> test_index_test_contrainst_that_has_a_very_long_name_to_trigger_the_character_limit
> on t(n);
> NOTICE: identifier
> "test_index_test_contrainst_that_has_a_very_long_name_to_trigger_the_character_limit"
> will be truncated to
> "test_index_test_contrainst_that_has_a_very_long_name_to_trigger"
> CREATE INDEX
> regression=# \d+ t
> Table "public.t"
> Column | Type | Modifiers | Storage | Stats target | Description
> --------+---------+-----------+---------+--------------+-------------
> n | integer | | plain | |
> Indexes:
> "test_index_test_contrainst_that_has_a_very_long_name_to_trigger"
> btree (n)
> Check constraints:
> "test_contrainst_that_has_a_very_long_name_to_trigger_the_charac"
> CHECK (n <> 1)
>
>
> Given where the identifier truncation behavior occurs, in the lexer, it
> would be mildly astonishing if it didn't work the same for both cases.
>
> regards, tom lane
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Josh Berkus 2015-10-01 18:48:43 Re: GRANT USAGE ON SEQUENCE missing from psql command completion
Previous Message David G. Johnston 2015-10-01 16:05:46 Re: BUG #13658: DELETE with syntax error in subselect deletes ALL