James Coleman <jtc...@gmail.com> writes: > I've been wondering recently why the external canonical form of types > like char and varchar doesn't match the typname in pg_type.
Mostly because the SQL standard wants certain spellings, some of which aren't even single words (e.g. DOUBLE PRECISION). There are cases where we could have changed internal names to match up with the spec name, but that won't work for all cases, and people have some attachment to the existing names anyway. > But I'm not following what would actually break if it weren't done > this way. Is the issue that a user defined type (in a different > schema, perhaps?) could overshadow the system type? That's one thing, and the rules about typmods are another. For instance the spec says that BIT without any other decoration means BIT(1), so that we have this: regression=# select '111'::bit; bit ----- 1 (1 row) versus regression=# select '111'::"bit"; bit ----- 111 (1 row) The latter means "bit without any length constraint", which is something the spec doesn't actually support. So when we have bit with typmod -1, we must spell it "bit" with quotes. > And would it make more sense (though I'm not volunteering right now to > write such a patch :D) to have these names be an additional column on > pg_type so that they can be queried by the user? Not particularly, because some of these types actually have several different spec-approved spellings, eg VARCHAR, CHAR VARYING, CHARACTER VARYING are all in the standard. regards, tom lane