From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | cpacejo(at)clearskydata(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #13666: REASSIGN OWNED BY doesn't affect the relation underlying composite type |
Date: | 2015-10-07 17:01:54 |
Message-ID: | 20151007170154.GB4405@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
cpacejo(at)clearskydata(dot)com wrote:
> =# CREATE TYPE foo AS (a integer, b integer);
>
> =# ALTER TYPE foo OWNER TO user1;
>
> =# SELECT typowner, relowner FROM pg_type JOIN pg_class ON typrelid =
> relfilenode WHERE typname = 'foo';
> -[ RECORD 1 ]---
> typowner | 16384
> relowner | 16384
>
> =# REASSIGN OWNED BY user1 TO user2;
>
> =# SELECT typowner, relowner FROM pg_type JOIN pg_class ON typrelid =
> relfilenode WHERE typname = 'foo';
> -[ RECORD 1 ]---
> typowner | 8713825
> relowner | 16384
Hmm. I guess we're missing a recursion step somewhere. I would have
assumed that the pg_class entry would also have a dependency on the
owner and should would have been visited in the initial loop. Strange.
> Furthermore, while trying to replicate in another database, I encountered:
>
> =# REASSIGN OWNED BY user1 TO user2;
> ERROR: unexpected classid 1418
>
> Not sure if this is related or not.
Not related. 1418 is pg_user_mapping (FDW stuff). Not sure what should
happen here; my inclination without thinking too hard is that REASSIGN
OWNED should ignore that object and DROP OWNED should remove it.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-10-07 21:56:09 | Re: BUG #13664: pg_restore fails with -j parameter when restoring 9.1 db onto 9.5 alpha db |
Previous Message | cpacejo | 2015-10-07 14:25:30 | BUG #13666: REASSIGN OWNED BY doesn't affect the relation underlying composite type |