Andrew Dunstan <and...@dunslane.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
