On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan <dar...@darrenduncan.net> wrote: > A key component of a good type system is that users can define data types, > and moreover where possible, system-defined types are defined in the same > ways as users define types. For example, stuff like temporal types or > geospatial types are prime candidates for being defined like user-defined > types.
They are user defined types, and even separately compiled, distributed, and dynamically linked. > You don't have to kludge things by implementing arrays as blobs for example; > you can implement them as relations instead. Geospatial types can just be > tuples. Arrays of structured types can just be relations with an attribute > per type attribute. Arrays of simple types can just be unary relations. In practice, my guess is the performance of these approaches would be terrible for a number of workloads. I don't agree that arrays having their own storage implementation is a kludge: there are even operators like unnest that can be used to turn them back into relations. I have long thought (but never really gave voice to) there being value having first-class relation values, but I would also say that's another kettle of fish. I also want closures, and don't think that's completely nuts. > I also want to emphasize that, while I drew inspiration from many sources > when defining Muldis D, and there was/is a lot I still didn't/don't know > about Postgres, I have found that as I use and learn Postgres, I'm finding > frequently that how Postgres does things is similar and compatible to how I > independently came up with Muldis D's design; I'm finding more similarities > all the time. You may want to learn more about this, first. Postgres's type system, while relatively simple, is not as ill-conceived or primitive as you seem to assume it is. There are also a lot of important system details, like expanding/replacing the typmod facility that only allows Postgres 32 bits of type-augmenting data (such as the (1) in the type numeric(1)). fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
