> Hmm. This looks like a CREATE TABLE implicitly creates a datatype
> that acts more or less like a C 'struct' declaration, ie, it's just a
> collection of subfields. OK, a struct-making declaration is certainly
> useful. What I don't understand yet is whether the contents of table
> "address" have any connection to the data stored in table "person".
> If not, why must I create a table in order to define a datatype? Seems
> like a separate CREATE DATATYPE command would make more sense...
I'm pretty sure that they were going for symmetry between simple data
types and more complex objects. Another example of this is creating an
empty table to be inherited by other tables, just to get a common
definition of fields.
Chris, one major reason why we run the risk of damaging the OR
features is that we don't have good coverage of these in the
regression tests. And as Tom pointed out, we aren't sure how to get at
the original Postgres papers and docs which might cover this in more
detail; the only thing we had directly was the old Postgres95 User's
Guide, which may not cover all of the possible features (in fact I
know it doesn't, since I made sure that all info in that guide
appeared somewhere in the newer docs).
I know that there are at least a few people with an interest in this
(including me, but I'm suffering from, among other things, a lack of
knowledge of what used to be there and what could be done). A great
first step would be documenting the behaviors one would expect in a
regression test, even if parts of that test currently fails.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
