Re: [HACKERS] Re: [SQL] Column name's length

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Re: [SQL] Column name's length
Дата
Msg-id 24842.928329417@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: [SQL] Column name's length  (wieck@debis.com (Jan Wieck))
Ответы Re: [HACKERS] Re: [SQL] Column name's length  (wieck@debis.com (Jan Wieck))
Re: [HACKERS] Re: [SQL] Column name's length  (Philip Warner <pjw@rhyme.com.au>)
Список pgsql-hackers
wieck@debis.com (Jan Wieck) writes:
>> Actually, we should use names not allowed in CREATE statements!
>> So I would use "pg_" prefix...

>     This would implicitly deny the user from dropping the created
>     index for a unique constraint :-) Same for  the  sequences  -
>     what's  good because they are used in the default clauses for
>     the serial field and dropping the sequence would corrupt  the
>     table though.

Well, it's only good if the system will get rid of the objects when
the user drops the owning table.  This is true for indexes but AFAIK
it is not yet true for sequences.  So if we go with pg_ prefix now,
there will be *no* way short of superuser privilege to get rid of the
sequence object for a deleted table that had a serial field.

Also, this will break pg_dump, which will have no good way to restore
the state of a serial sequence object.  (CREATE SEQUENCE pg_xxx will
fail, no?)

>     I like it.

Perhaps eventually we should wind up using names like "pg_pkey_8381292"
but I think this ought to wait until the system retains an explicit
representation of the relationship between these indexes/sequences and
the owning table, and until we think through the consequences for
pg_dump.  For now we had better stick to unprivileged names.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: Rules puzzle with "current" keyword.
Следующее
От: Massimo Dal Zotto
Дата:
Сообщение: Re: [HACKERS] nonblocking lock?