Skip site navigation (1) Skip section navigation (2)

Re: Patch to add a primary key using an existing index

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, Steve Singer <ssinger(at)ca(dot)afilias(dot)info>
Cc: Steve Singer <ssinger_pg(at)sympatico(dot)ca>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to add a primary key using an existing index
Date: 2010-11-29 01:06:42
Message-ID: AANLkTin04diTRki2iV9PHyKk_GHU0SSQ7-h5_OQBzS7u@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Nov 26, 2010 at 05:58, Steve Singer <ssinger(at)ca(dot)afilias(dot)info> wrote:
> The attached version of the patch gets your regression tests to pass.
> I'm going to mark this as ready for a committer.

I think we need more discussions about the syntax:
  ALTER TABLE table_name ADD PRIMARY KEY (...) WITH (INDEX='index_name')

Issues:
* WITH (...) is designed for storage parameters. I think treating "INDEX"
  as a special keyword in the way might be confusable.
* 'index_name' needs to be single-quoted, but object identifiers should
  be double-quoted literals in normal cases.
* The key specifier is a duplicated option because the index has own keys.
  Do we need it? It might be for safety, but redundant.
  Note that the patch raises a reasonable error on conflict:
ERROR:  PRIMARY KEY/UNIQUE constraint definition does not match the index

And, I found a bug:
* USING INDEX TABLESPACE clause is silently ignored, even if the index
  uses another tablespace.

After all, do we need a special syntax for the functionality?
Reusing WITH (...) syntax seems to be a trouble for me.
"ADD PRIMARY KEY USING index_name" might be a candidate, but we'd
better reserve USING for non-btree PRIMARY KEY/UNIQUE indexes.
Ideas and suggestions?

-- 
Itagaki Takahiro

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-11-29 01:14:23
Subject: Re: Assertion failure on hot standby
Previous:From: Tom LaneDate: 2010-11-29 01:01:35
Subject: Re: profiling connection overhead

Privacy Policy | About PostgreSQL
Copyright © 1996-2013 The PostgreSQL Global Development Group