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
