| From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
|---|---|
| To: | "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net> |
| Cc: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] Finding primary keys in a table |
| Date: | 1998-07-21 01:41:21 |
| Message-ID: | 35B3F1C1.CE513FB8@alumni.caltech.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > Because we just create a unique index on a PRIMARY specification, I
> > think any unique index on a field shows it as primary.
> Hmm. Any chance we can somehow flag it as well? Perhaps a new bool
> field in pg_index the next time we do a dump & reload release? I
> assume we will need it eventually anyway.
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?
- Tom
| From | Date | Subject | |
|---|---|---|---|
| Next Message | The Hermit Hacker | 1998-07-21 01:57:27 | Re: [HACKERS] cidr |
| Previous Message | The Hermit Hacker | 1998-07-21 00:22:38 | Re: [HACKERS] cvs and empty directories |