Re: Refactoring the Type System

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> This is so general as to be quite meaningless to me. What is it that is
> wanted that we don't have. (And don't say "flexibility", that's way too
> general - say something much more concrete and specific. If you want
> flexibility we can store everything as text, but I doubt you'll like the
> result.)

The way I understand it is (unsurprisingly) related to user data in
extensions. PostGIS maintains a table of user attributes related to
their types, if I've understood correctly. Things that won't fit in the
typmod, that will be different depending on the columns or some other
environment meta-data, and that will have consequences on the meaning
and running of user queries.

Ok, that's not that more precise, but that's a typmod which does not fit
in 32 bits so is saved away in some PostGIS table and referred to from
the main storage.

About all the other problems with the type system flexibility that I've
read on, I think they are in the "type inference" category: we like the
strong typing of the database system but would like it to get forgotten
about. The paramount of this I think was the proposal of the LAMBDA
expressions at the time the DO utility statement appeared.

I don't know how far in the type inference system we want to go (but I
think we already have parts of that in our implicit cast rules). Maybe
we want to think about having (user) functions be types, too.

Also, tables are some types already, and JOINs and resultsets are
relations too, so they are some types too. I don't know how far the
current typing system is considering tables and joins and relation as
the same thing as types, but there's something there with NULL handling
and some ROW and record facilities that we see surprised people about in
-bugs and other places.

Well, just my very unorganised 2¢,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support