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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jwieck(at)debis(dot)com (Jan Wieck)
Cc: vadim(at)krs(dot)ru (Vadim Mikheev), lockhart(at)alumni(dot)caltech(dot)edu, pgsql-hackers(at)postgreSQL(dot)org, zalman(at)netcom(dot)com
Subject: Re: [HACKERS] Re: [SQL] Column name's length
Date: 1999-06-02 13:16:57
Message-ID: 24842.928329417@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

wieck(at)debis(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-06-02 13:41:56 Re: [HACKERS] Re: [SQL] Column name's length
Previous Message Jan Wieck 1999-06-02 11:49:11 Re: Rules puzzle with "current" keyword.