James Coleman <jtc331@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