Re: [HACKERS] Finding primary keys in a table

From: darcy(at)druid(dot)net (D'Arcy J(dot)M(dot) Cain)
To: lockhart(at)alumni(dot)caltech(dot)edu (Thomas G(dot) Lockhart)
Cc: maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian), pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Finding primary keys in a table
Date: 1998-07-21 13:33:08
Message-ID: m0yycXU-00006FC@druid.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thus spake Thomas G. Lockhart
> I'm not sure I understand all the issues, but if we can avoid
> distinctions between different indices that would be A Good Thing. Since
> multiple unique indices are allowed, what would be the extra
> functionality of having one designated "primary"? Is it an arbitrary
> SQL92-ism which fits with older databases, or something which enables
> new and interesting stuff?

Well, in database design there is a distinction between indeces and
keys. Being able to specify this distinction in the database seems
useful to me from a database designer perspective.

Here's how I use that distinction in my Python code.

data = db_get(db, customer, client_id)
data = db_get(db, province, data)

The first line gets the client record based on the client ID. The next
line gets the information on the client's province such as full name,
tax rate, etc. It does this because it knows that prov, the two letter
code field, is the primary key on province and it can find the prov
field in the data dictionary which came from the customer class. This
is similar to how some 4GLs do it.

FIND FIRST customer WHERE client_id = x, province OF customer.

Certainly there are alternate ways of doing this but it is nice to be
able to put as much information into the RDBMS as possible. Codd's
first rule might be used in support of this.

"All information represented only in tables."

--
D'Arcy J.M. Cain <darcy(at){druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthew N. Dodd 1998-07-21 14:00:03 Re: [HACKERS] cidr
Previous Message The Hermit Hacker 1998-07-21 12:11:47 Re: [HACKERS] cidr