On Fri, Jul 31, 2026 at 10:58:41PM -0400, Tom Lane wrote: > Ken Harris <[email protected]> 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 <[email protected]> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
