| From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
|---|---|
| To: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
| Cc: | "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net>, hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] Adding PRIMARY KEY info |
| Date: | 1998-09-03 01:11:01 |
| Message-ID: | 35EDECA5.2A5641F9@krs.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas G. Lockhart wrote:
>
> Hmm. How about having a "primary key" flag field in pg_index instead? We
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I like this.
> could enforce integrity in the parser, since we can check that only one
> primary key has been specified during the parsing. You might be able to
> define a trigger on pg_index to update pg_class (if you still needed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Impossible. Triggers are handled by executor, not by heap access
methods...
> that column) if the key field is set.
>
> btw, if any of this is worth doing it is perhaps to allow us to
> implement foreign keys later (assuming that primary and foreign keys are
> related which is what I am recalling). How would we tie key information
> together and enforce integrity? I haven't thought about it yet. Also,
> Vadim was thinking about doing something for foreign keys, so we should
> ask him where he was headed with that...
Imho, indices should be used/created for FOREIGN keys and so pg_index
is good place for both PRIMARY and FOREIGN keys infos.
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vadim Mikheev | 1998-09-03 01:15:33 | Re: default values |
| Previous Message | Keith Parks | 1998-09-03 00:46:24 | Re: [HACKERS] Fix for initdb/indexing problems |