Doc patch: Document names of automatically created constraints and indexes - Mailing list pgsql-hackers

From Karl O. Pinc
Subject Doc patch: Document names of automatically created constraints and indexes
Date
Msg-id 1352737596.21373.1@mofo
Whole thread Raw
Responses Re: Doc patch: Document names of automatically created constraints and indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

Attached is a patch (against head) which documents the
name of the constraint and index created when using
PRIMARY KEY with CREATE TABLE, and the name of the
index created when using UNIQUE.  I haven't read all
the docs recently but I don't believe this is presently
documented.

It's unclear to me that this is the right approach
but perhaps this will start a discussion that finds
the right approach.

The big problem I see is that these are somewhat of
an implementation internal while at the same
time being something that the user might have to
concern themselves with.

First, the constraint and index
names are in the namespace used by the user so there
is potential for collision with user-defined
constraints and indexes.

Second, the only way (I know of) to remove primary-key-ness
is to drop the primary key constraint, by name.

This lead me right into another thought:
It would be nice to have ALTER TABLE be able to
drop the primary key constraint.  (Then the
user would not need to know the name of the
constraint related to primary-key-ness.)
However, it is probably more useful to be able
to drop the constraint (and attendant foreign
key meta-information) separately from the unique
index associated with the primary key, if for no
other reason than index re-creation can be expensive
and missing indexes make bad things happen.

This patch is the improvement I could come up
with.  Someone else can decide to commit or reject,
I don't believe I can contribute much more on this at this
time.

Regards,

Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Further pg_upgrade analysis for many tables
Next
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] Patch to compute Max LSN of Data Pages