Re: [HACKERS] Re: ORDBMS
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] Re: ORDBMS |
Дата | |
Msg-id | 3891B8DA.9FA3073E@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: ORDBMS (Peter Eisentraut <e99re41@DoCS.UU.SE>) |
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: