Re: Shadowing type names because I am not smart

Ken Harris <kengruven(at)gmail(dot)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.

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