On Fri, Jul 31, 2026 at 10:58:41PM -0400, Tom Lane wrote:
> Ken Harris <kengruven@gmail.com> writes:
> > My message admittedly wandered a bit, but if I had to narrow it down to one
> > point of confusion for me, it'd be:
>
> > Why does shadowing the name of a built-in type behave differently, for
> > different built-in types?
>
> The short answer here is that some "built-in" types just have names
> that are in the pg_type catalog, while others have names that are
> recognized by the grammar and translated to pg_type names. For
> example, "double precision" is not a type name per the basic rules,
> but the SQL standard demands that we recognize it. So the grammar
> has a production that translates that to "pg_catalog.float8" ---
> not just float8 --- and that means that a user-defined type can't
> override the meaning of "double precision" no matter what the
> search path is. Another example is that "integer" is the name
> called out by the SQL spec for the type that is entered in
> pg_type as "int4". So "integer" is translated to "pg_catalog.int4"
> and you can't override that, but you could override plain "int4"
> depending on search_path. Conversely, some error messages translate
> type OIDs back to the SQL-standard names, but I suspect that not all
> do; there may be places that just report the pg_type name.
Should we prohibit users from creating types that are hard-coded into
the grammar?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
