Re: BUG #13666: REASSIGN OWNED BY doesn't affect the relation underlying composite type

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

In response to

Responses

Browse pgsql-bugs by date

  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