On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan <darren@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