> I tried adding the PRIMARY KEY info to pg_class but the resulting data
> base system simply dumps core everywhere.
> The next step, of course, is to turn PRIMARY KEY statements into an
> update to the class table to insert the oid of the KEY field. I
> looked at parser/analyze.c but I think I have to look deeper.
I'm not sure this is easy (or possible :), but don't really know. The
multi-parse-tree expansions I've done in the parser do not try to take
results and use them as input to a different parse tree. I think if I
were trying this I'd look at triggers firing after an insert, but I'm
not sure how you would tie things together since the "primary key" is
implmented as just a unique index in the backend.
Hmm. How about having a "primary key" flag field in pg_index instead? We
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
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...
- Tom
