Daniel Farina wrote:
> On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan <darren@darrenduncan.net> wrote:
>> 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'm not discounting this at all. The data model can formally define types in
one way and a DBMS can implement various well known cases in specialized ways
that are more efficient. Arrays are a good example. But with other cases they
still get a default implementation. If arrays are flexible enough, then
different arrays could be implemented differently, eg some as blobs and some as
relations; the former could be better for small or simple arrays and the latter
for large or complex arrays.
> 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 think that first-class functions are important at least, if not full-blown
closures. You can define generic relational restrictions or summaries or
whatever with such; eg, the general case of a WHERE is a function that takes a
relation and a function as input, and results in a relation; more restricted
cases of WHERE can be defined with simpler functions that take 2 relation inputs
instead.
> 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)).
I'm not saying that Pg's system is primitive et al. The thread starter said it
needed an overhaul, so indicating there are deficiencies, and I'm suggesting
some effective ways to do that.
-- Darren Duncan