Re: Odd behavior with domains

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Odd behavior with domains
Date: 2016-06-24 17:08:47
Message-ID: 576D691F.9060601@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/23/2016 08:00 PM, Alvaro Herrera wrote:
> Joshua D. Drake wrote:
>> Hey,
>>
>> So this came across my twitter feed:
>>
>> https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png
>>
>> I have verified the oddness with a newer version:
>
> 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.

Yes but what makes it weird is this:

postgres=# create domain text char(3);
CREATE DOMAIN

-- cool, no problem

postgres=# create domain text char(2);
ERROR: type "text" already exists

-- as expected

postgres=# \dD
List of domains
Schema | Name | Type | Modifier | Check
--------+------+------+----------+-------
(0 rows)

-- wait what? I just created this.
-- I understand the search_path issue but:

postgres=# create domain textd char(2);
CREATE DOMAIN
postgres=# \dD
List of domains
Schema | Name | Type | Modifier | Check
--------+-------+--------------+----------+-------
public | textd | character(2) | |
(1 row)

-- why would this show up without changing the search path if the
-- previous one didn't?

postgres=# drop domain text;
ERROR: "text" is not a domain
postgres=# set search_path to 'public';
SET
postgres=# drop domain text;
ERROR: "text" is not a domain
postgres=#

-- Now what?

Note: If this is literally just the way it is, cool. It was just as I
was exploring this all seemed odd.

Sincerely,

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2016-06-24 17:15:30 Re: Bug in to_timestamp().
Previous Message Steve Crawford 2016-06-24 16:26:21 Re: Bug in to_timestamp().