Re: Refactoring the Type System

David Fetter wrote:
> For the past couple of years, I've been hearing from the PostGIS
> people among others that our type system just isn't flexible enough
> for their needs. It's really starting to show its age, or possibly
> design compromises that seemed reasonable a decade or more ago, but
> are less so now.
>
> To that end, I've put up a page on the wiki that includes a list of
> issues to be addressed. It's intended to be changed, possibly
> completely.
>
> http://wiki.postgresql.org/wiki/Refactor_Type_System
>
> What might the next version of the type system look like?

Are you talking about changes to the type system as users see it or just changes
to how the existing behavior is implemented internally? If you're talking
about, as users see it, which the other replies to this thread seem to be
saying, though not necessarily the url you pointed to which looks more internals ...

As a statement which may surprise no one who's heard me talk about it before ...

I've mostly completed a type system specification that would be useable by
Postgres, as the most fundamental part of my Muldis D language.

The type system is arguably the most central piece of any DBMS, around which
everything else is defined and built.

You have data, which is structured in some way, and has operators for it.

If you look at a DBMS from the perspective of being a programming language
implementation, you find that a database is just a variable that holds a value
of a structured type. In the case of a relational database, said database is a
tuple whose attribute values are relations; or in the case of
namespaces/schemas, the database tuple has tuple attributes having relation
attributes.

If a database is a variable, then all database constraints are type constraints
on the declared type of that variable, and you can make said constraints
arbitrarily complicated.

From basic structures like nestable tuples and relations, plus a complement of
basic types like numbers and strings, and arbitrary constraints, you can define
data types of any shape or form.

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.

If you define all structures using tuples and relations, you can easily flatten
this out on the implementation end and basically do everything as associated
flat relation variables as you do now.

So what I propose is both very flexible and easy to implement, scale, and
optimize, relatively speaking.

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.

You can also emulate all of the existing Pg features and syntax that you have
now over the type system I've defined, maintaining compatibility too.

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.

-- Darren Duncan