From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Odd behavior with domains |
Date: | 2016-06-24 19:04:28 |
Message-ID: | CA+Tgmob_kt_ObpwbxciCh7afWD+wgXPCif2zfPkK7Mu7h=+1Rw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 23, 2016 at 11:00 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Well, it's not specifically related to domains -- it's related to the
> fact that pg_catalog objects mask the domain you created in the public
> schema, because pg_catalog is by default in front of all other schemas
> unless you explicitely put it elsewhere.
Well, what's causing the apparent weirdness here is the fact that
pg_catalog, despite being implicitly at the front of the namespath
path, doesn't become the default creation schema as an
explicitly-named schema would. So you don't try to create things
there but anything that already exists there masks the stuff you do
create. And I think it's fair to say that's pretty weird to someone
who is unfamiliar with the way the system works.
We could do something like this:
NOTICE: existing type "pg_catalog"."text" will mask new type "public"."text"
We could even make that an ERROR by default, as long as we had some
GUC to disable the behavior for pg_dump. How often do you really
intentionally create an object that shadows an existing system object?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-06-24 19:14:46 | Re: Postgres_fdw join pushdown - wrong results with whole-row reference |
Previous Message | Robert Haas | 2016-06-24 18:39:01 | Re: Cleanup in contrib/postgres_fdw/deparse.c |