agora inbox for pgsql-docs@postgresql.org
help / color / mirror / Atom feedRe: Shadowing type names because I am not smart
4+ messages / 4 participants
[nested] [flat]
* Re: Shadowing type names because I am not smart
@ 2026-07-30 12:45 David G. Johnston <david.g.johnston@gmail.com>
2026-08-01 02:38 ` Re: Shadowing type names because I am not smart Ken Harris <kengruven@gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: David G. Johnston @ 2026-07-30 12:45 UTC (permalink / raw)
To: kengruven@gmail.com <kengruven@gmail.com>; pgsql-docs@lists.postgresql.org <pgsql-docs@lists.postgresql.org>
On Wednesday, July 29, 2026, PG Doc comments form <noreply@postgresql.org>
wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/18/sql-syntax-lexical.html
> Description:
>
> This is all on Linux (Debian stable), using Postgres 17.9.
In this case reading the v18 docs and experimenting on v17 is problematic
since the defaults have changed.
Public schema is in the search_path in v17. The implied pg_catalog entry
only exists when searching the search_path during resolution, not when
trying to find a schema into which to create an object.
So yes, creating a type shadowed by a system type behaves as shown. It can
be created without schema qualification but cannot be found that way with a
safe search_path.
David J.
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Shadowing type names because I am not smart
2026-07-30 12:45 Re: Shadowing type names because I am not smart David G. Johnston <david.g.johnston@gmail.com>
@ 2026-08-01 02:38 ` Ken Harris <kengruven@gmail.com>
2026-08-01 02:58 ` Re: Shadowing type names because I am not smart Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 4+ messages in thread
From: Ken Harris @ 2026-08-01 02:38 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: pgsql-docs@lists.postgresql.org <pgsql-docs@lists.postgresql.org>
Hi again,
First, sorry about the URL. I composed my email in my text editor, and
then came back to the form later by clicking on the first "please use this
form" link on a Postgres documentation page I had open. The URL isn't
visible on the form, and I didn't realize it would be part of the email
until after I'd submitted it.
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?
Sometimes they appear in \dT, and sometimes they don't.
Sometimes you can refer to them by "quoting" them, and sometimes you need
to schema.qualify them.
Sometimes error messages refer to the type as you wrote it, and sometimes
by an "extension" name for that type.
and so on
Any mental model that I hypothesized, based on one type, failed when I
tried to use it to explain what I saw with a different type. I'm unable to
find anything in the documentation which explains why some built-in types
would act differently than others in any of these ways.
Anyway, thanks for listening! My lesson from this is: this is one of those
areas which you should really just avoid.
- Ken
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Shadowing type names because I am not smart
2026-07-30 12:45 Re: Shadowing type names because I am not smart David G. Johnston <david.g.johnston@gmail.com>
2026-08-01 02:38 ` Re: Shadowing type names because I am not smart Ken Harris <kengruven@gmail.com>
@ 2026-08-01 02:58 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-08-20 21:31 ` Re: Shadowing type names because I am not smart Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 4+ messages in thread
From: Tom Lane @ 2026-08-01 02:58 UTC (permalink / raw)
To: Ken Harris <kengruven@gmail.com>; +Cc: David G. Johnston <david.g.johnston@gmail.com>; pgsql-docs@lists.postgresql.org <pgsql-docs@lists.postgresql.org>
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.
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Shadowing type names because I am not smart
2026-07-30 12:45 Re: Shadowing type names because I am not smart David G. Johnston <david.g.johnston@gmail.com>
2026-08-01 02:38 ` Re: Shadowing type names because I am not smart Ken Harris <kengruven@gmail.com>
2026-08-01 02:58 ` Re: Shadowing type names because I am not smart Tom Lane <tgl@sss.pgh.pa.us>
@ 2026-08-20 21:31 ` Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 4+ messages in thread
From: Bruce Momjian @ 2026-08-20 21:31 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Ken Harris <kengruven@gmail.com>; David G. Johnston <david.g.johnston@gmail.com>; pgsql-docs@lists.postgresql.org <pgsql-docs@lists.postgresql.org>
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.
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-08-20 21:31 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-07-30 12:45 Re: Shadowing type names because I am not smart David G. Johnston <david.g.johnston@gmail.com>
2026-08-01 02:38 ` Ken Harris <kengruven@gmail.com>
2026-08-01 02:58 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-08-20 21:31 ` Bruce Momjian <bruce@momjian.us>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox