| From: | darcy(at)druid(dot)net (D'Arcy J(dot)M(dot) Cain) |
|---|---|
| To: | daveh(at)insightdist(dot)com (David Hartwig) |
| Cc: | pgsql-hackers(at)postgreSQL(dot)org (pgsql-hackers) |
| Subject: | Re: [HACKERS] Serial Data Type |
| Date: | 1998-09-12 02:11:31 |
| Message-ID: | m0zHf9v-00006FC@druid.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thus spake David Hartwig
> I have a couple minor issues regarding the 6.4 implementation of the
> SERIAL data type. I like the ease of using the serial data type and I
> suspect it will be used frequently base on the number of inquiries over
> the past months.
>
> 1. Should the sequence created by the serial type declaration, be
> dropped as a result of dropping the parent table?
Sounds like a good idea.
> 2. Can a declared serial column be also a primary key? If so, what
> will be the side effected? Specifically, how will the unique index be
> named? The ODBC driver uses the {relname}_pkey to identify the primary
> key of a table. The driver must be able to identify primary keys.
I suspect that the serial field will be the primary key 99% of the time.
I hope it can be.
As for finding the primary, with the new changes we should be able
to do something like this.
SELECT pg_class.relname, pg_attribute.attname
FROM pg_class, pg_attribute, pg_index
WHERE pg_class.oid = pg_attribute.attrelid AND
pg_class.oid = pg_index.indrelid AND
pg_index.indkey[0] = pg_attribute.attnum AND
pg_index.indisprimary = 't';
--
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | D'Arcy J.M. Cain | 1998-09-12 02:14:40 | Re: [HACKERS] SERIAL data type |
| Previous Message | Tatsuo Ishii | 1998-09-12 01:23:55 | SERIAL data type |