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. It doesn't look like we have this situation documented terribly well, short of looking into gram.y for typename-related productions. The table in https://www.postgresql.org/docs/current/datatype.html leaves the impression that the SQL type names are ground truth and the other names are aliases, which is basically backwards from implementation reality. For Postgres, the names in pg_type are ground truth and the other ones are aliases. regards, tom lane
