Re: Odd behavior with domains

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

In response to

Browse pgsql-hackers by date

  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