> 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

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

Reply via email to