Re: [HACKERS] Re: [SQL] Column name's length - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Re: [SQL] Column name's length
Date
Msg-id 24842.928329417@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: [SQL] Column name's length  (wieck@debis.com (Jan Wieck))
Responses Re: [HACKERS] Re: [SQL] Column name's length
Re: [HACKERS] Re: [SQL] Column name's length
List 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 by date:

Previous
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: Rules puzzle with "current" keyword.
Next
From: Massimo Dal Zotto
Date:
Subject: Re: [HACKERS] nonblocking lock?