Stephan Szabo wrote:
>
> Of course I had to be half asleep when I wrote the second paragraph of my
> response, since I totally missed he was using a serial. The rest still
> applies though...
>
> As an aside to Chris, what interactions do you expect between the OO stuff
> you've been working on and foreign key references? I'm going to have to
> muck around with the trigger code to move to storing oids of tables and
> attributes rather than names, so I thought it might make sense to at least
> think about possible future interactions.
As a rule, anything that applies to a base class should also apply to
the sub-class automatically. For some things you may want to have the
option of excluding it, by something like the ONLY syntax of select, but
99% of the time everything should just apply to sub-classes.
Storing oids of attributes sounds like a problem in this context because
it may make it hard to relate these to sub-classes. I do really think
that the system catalogs should be re-arranged so that attributes have
two parts - the parts that are specific to that class, and the parts
that also apply to sub-classes. For example the type and the length
should probably apply to sub-classes. The attnum and the name should
probably be individual to each class in the hierarchy. (The name should
be individual to support subclass renaming to avoid naming conflicts,
like in the draft SQL3 and Eiffel). If it is in two parts then using the
oid of the common part would make it easy for your purposes.
