Search Postgresql Archives

Re: Is a primary key made of a couple columns so much better than a unique() constraint ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Martijn van Oosterhout <kleptog@xxxxxxxxx> writes:
> On Mon, Oct 10, 2005 at 04:44:54PM +0200, David Pradier wrote:
>> i'd like to know if it is better to use a primary key made of a couple
>> columns, than to use a constraint UNIQUE() on this couple columns,
>> regarding the sake of postgresql.

> In PostgreSQL, both primary keys and UNIQUE constraints are implemented
> via UNIQUE indexes, ergo there is no difference...

Just for the sake of completeness, there are exactly two differences:

* PRIMARY KEY implies NOT NULL on the key columns; UNIQUE doesn't.

* PRIMARY KEY creates a default target for foreign key references,
  ie, if you've declared a primary key then you can later just say
  "REFERENCES mytab" instead of spelling out "REFERENCES mytab(keycol)".

So "UNIQUE + NOT NULL" is pretty dang close to the same as "PRIMARY
KEY", but not quite.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux