Re: 7.0.0 long name truncation problem - Mailing list pgsql-general

From Gregory Wood
Subject Re: 7.0.0 long name truncation problem
Date
Msg-id 009e01c0dc82$dfa44d80$7889ffcc@comstock.com
Whole thread Raw
In response to 7.0.0 long name truncation problem  (Ed Loehr <ed@www.accuros.com>)
Responses New article mentions Postgres...  ("Brent R. Matzelle" <bmatzelle@yahoo.com>)
List pgsql-general
> When the name of a sequence auto-generated from a SERIAL type would be
> longer than 32 chars, it appears that "CREATE TABLE" uses a different
> name truncation algorithm than "DROP SEQUENCE".  Example below.  Note
> the difference between the following:
>
>         'process_state_subscripti_id_seq'
>         'process_state_subscription_id_s'

The problem is that the CREATE TABLE statement uses the table name, field
name and an identifier "_seq" to generate the sequence name. Because it
knows those values, it is able to intelligently truncate values.

The DROP SEQUENCE statement doesn't know the table name, the field name, or
even that the sequence is being used for a SERIAL field. All it knows is
that the name can't be longer than 32 characters. So when you feed it a
string, the only thing it can really do: truncate the end. It *might* be
possible to parse the string based on separators (underscores) except that
in your example, you use underscores in your table/field names as well, so
what's it to do?

> Might be fixed in 7.1, I dunno.  Can anyone confirm this is a problem?

It's a problem for people like you and me, but it's expected behavior.
Personally, I'd love to see someone add a DROP SERIAL that would accept the
Table and Field name and then generate the DROP SEQUENCE statement for you
(hint, hint *g*).

Greg


pgsql-general by date:

Previous
From: "Gregory Wood"
Date:
Subject: Re: What's the best front end/client under MS Windows?
Next
From: Tom Lane
Date:
Subject: Re: Speeding up Query