Обсуждение: [var]char versus character [varying]

I've been wondering recently why the external canonical form of types
like char and varchar doesn't match the typname in pg_type.
Additionally, the alternative/extended names are hardcoded in
format_type.c rather than being an additional column in that catalog
table.

I would have assumed there were largely historical reasons for this,
but I see the following relevant comments in that file:

/*
* See if we want to special-case the output for certain built-in types.
* Note that these special cases should all correspond to special
* productions in gram.y, to ensure that the type name will be taken as a
* system type, not a user type of the same name.
*
* If we do not provide a special-case output here, the type name will be
* handled the same way as a user type name --- in particular, it will be
* double-quoted if it matches any lexer keyword. This behavior is
* essential for some cases, such as types "bit" and "char".
*/

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?

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?

Thanks,
James

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