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
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 |