I defined type SESSION# as a subtype of INTEGER on the constraint INTEGER > 0. This type was for use as the declared type of a particular attribute in some particular base relvars.
When I gave a query in DBrowser, one of whose result attributes was defined by ADD ( COUNT() AS NoOfThings ), I was a bit surprised to see "NoOfThings SESSION#(2)" in the result display instead of just "NoOfThings 2". (Of course, DBrowser showed just "NoOfThings 0" for tuples representing a zero count, because 0 isn't a value of type SESSION #.)
This observation raises an issue that I'm not sure the inventors of Tutorial D (with type inheritance) considered. It appears that Rel (or DBrowser?) is computing the most specific type of each value and then using a selector for that type when constructing a literal to appear in the rendering of the result. I have previously claimed that it is never necessary to compute MSTs, and I've done that to fend off a possible criticism of our model that frequent MST computation would severely impair performance.
According to Date and Darwen's type theory, it would be anti-model to have a second type defined on exactly the same constraint, IS INTEGER CONSTRAINT (INTEGER > 0), but Rel can't stop me doing that and I wonder which selector it would then choose when COUNT() yields a value greater than zero.
Perhaps it would be better, in general, to use a selector determined by the declared type of the attribute in question, rather than the MST of each value for that attribute. But even then the system might have to make an arbitrary choice, when two or more possreps are given for the same UDT.
This forum is for any questions about the language Tutorial D or the Rel implementation of it.
1 post • Page 1 of 1