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
Re: [HACKERS] Re: [SQL] Column name's length |
Список | 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 по дате отправления: