Re: 7.0.0 long name truncation problem

Поиск
Список
Период
Сортировка
От Gregory Wood
Тема Re: 7.0.0 long name truncation problem
Дата
Msg-id 009e01c0dc82$dfa44d80$7889ffcc@comstock.com
обсуждение исходный текст
Ответ на 7.0.0 long name truncation problem  (Ed Loehr <ed@www.accuros.com>)
Ответы New article mentions Postgres...  ("Brent R. Matzelle" <bmatzelle@yahoo.com>)
Список 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 по дате отправления:

Предыдущее
От: "Gregory Wood"
Дата:
Сообщение: Re: What's the best front end/client under MS Windows?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Speeding up Query