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: | Raw Message | Whole Thread | 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 |