On Dec 4, 2010, at 1:30 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Ross J. Reedstrom" <reeds...@rice.edu> writes: >> If you consider that an index basically is, in some sense, a pre-canned >> column list, then: > >> ALTER TABLE table_name ADD PRIMARY KEY (column_list); >> ALTER TABLE table_name ADD PRIMARY KEY USING index_name; > >> are parallel constructions. And it avoids the error case of the user >> providing a column list that doesn't match the index. > > +1 for that approach. One other thought is that ordinarily, the > add-constraint syntax ensures that the constraint is named the same as > its underlying index; in fact we go so far as to keep them in sync if > you rename the index later. But after > > ALTER TABLE table_name ADD CONSTRAINT con_name PRIMARY KEY USING index_name; > > they'd be named differently, unless we (a) throw an error or (b) > forcibly rename the index. Neither of those ideas seems to satisfy the > principle of least surprise, but leaving it alone seems like it will > also lead to confusion later.
I think that might be the best way though. > I wonder whether, in the same spirit as not letting the user write a > column name list that might not match, we should pick a syntax that > doesn't allow specifying a constraint name different from the index > name. In the case where you say CONSTRAINT it'd be a bit plausible > to write something like > > ALTER TABLE table_name ADD CONSTRAINT con_name PRIMARY KEY USING EXISTING > INDEX; > > (implying that the index to use is named con_name) but I don't know > what to do if you want to leave off the "CONSTRAINT name" clause. Because this seems plain weird. ...Robert > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
