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

Re: Data type to use for primary key

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Cc: Rod Taylor <pg(at)rbt(dot)ca>,Alexandre Leclerc <alexandre(dot)leclerc(at)gmail(dot)com>
Subject: Re: Data type to use for primary key
Date: 2004-11-23 06:00:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance

> It would be nice if PostgreSQL had some form of transparent surrogate
> keying in the background which would automatically run around and
> replace your real data with SERIAL integers. It could use a lookup table
> for conversions between the surrogate and real values so the user never
> knows that it's done, a bit like ENUM. Then we could all use the real
> values with no performance issues for 1) because it's an integer in the
> background, and 2) because a cascade only touches a single tuple in the
> lookup table.

Sybase does this, and it's a feature I would dearly love to emulate.  You can 
just refer to another table, without specifying the column, as an FK and it 
will create an invisible hashed key.   This is the type of functionality Codd 
was advocating -- invisible, implementation-automated surrogate keys -- in 
the mid 90's (don't have a paper citation at the moment).

So you'd just do:

create table client_contacts (
	fname text not null,
	lname text not null,
	client foriegn key clients,
	position text,
	notes text

and the "client" column would create an invisible hashed key that would drag 
in the relevant row from the clients table; thus a:

select * from client_contacts

would actually show the whole record from clients as well.

Josh Berkus
Aglio Database Solutions
San Francisco

In response to


pgsql-performance by date

Next:From: Pierre-Frédéric CaillaudDate: 2004-11-23 08:39:52
Subject: Re: Data type to use for primary key
Previous:From: Bruce MomjianDate: 2004-11-23 02:26:05
Subject: Re: scalability issues on win32

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