Re: Refactoring the Type System

On Fri, 2010-11-12 at 08:34 -0800, David Fetter wrote:
> Folks,
>
> 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?

This problems (as stated) strikes me as pretty overwhelming.

1. As far as I can tell, we have the best type system of any SQL DBMS.
2. Getting a type system right is a hard problem by itself, and there
isn't any obvious consensus (although I think there is some agreement on
some issues).
3. Type systems are more challenging for a DBMS because you need to
account for things like storage, indexing, and optimization in ways that
programming languages don't (consider: when comparing an int4 and an
int8, you may want to coerce based on what indexes you have available).
4. SQL standard issues. In particular, I think that any modern type
system will run into pretty severe problems with NULLs in one way or
another. I think we'd have to pay very close attention to the standard
when designing a new type system, because I suspect that retrofitting
the standard onto a system we invent independently would be a disaster.
5. Backwards compatibility issues.

I think the best we'll do is be able to hack on some of the things that
we actively want and have clear use cases for, such as type interfaces.
We might have to give up on some of the more ambitious ideas that
involve propagating interesting information through the type inference
system; or having any real type that wasn't declared with CREATE TYPE.
Consider that right now we bundle the element type information along
with the array _value_.

Ideas welcome. Particularly if there are a few clear use cases.

Regards,
Jeff Davis