[var]char versus character [varying]

From: James Coleman <jtc331(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: [var]char versus character [varying]
Date: 2020-10-23 18:06:32
Message-ID: CAAaqYe8rOw_5jdzm5LqdoUMPQum82gwGo10xMFr57FYpvW4UMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2020-10-23 18:10:39 Re: vacuum -vs reltuples on insert only index
Previous Message Tom Lane 2020-10-23 18:04:25 Re: new heapcheck contrib module