Re: pg_dump fails to set index ownership - Mailing list pgsql-bugs

On Tue, Jan 11, 2005 at 12:25:31AM -0500, Tom Lane wrote:

> A related point is that ALTER TABLE ... OWNER does not recurse to
> the table's indexes.

Eh?  ALTER TABLE ... OWNER won't touch the indexes if the table
owner doesn't change, but if the table owner changes then so do
the index owners.  I don't know what behavior is intended, but
that's what currently happens:

SELECT relname, relkind, relowner FROM pg_class WHERE relname LIKE 'foo%';
  relname   | relkind | relowner
------------+---------+----------
 foo        | r       |      100
 foo_id_seq | S       |      100
 foo_pkey   | i       |        1
(3 rows)

ALTER TABLE foo OWNER TO mfuhr;  -- mfuhr = 100, so no table owner change
SELECT relname, relkind, relowner FROM pg_class WHERE relname LIKE 'foo%';
  relname   | relkind | relowner
------------+---------+----------
 foo        | r       |      100
 foo_id_seq | S       |      100
 foo_pkey   | i       |        1
(3 rows)

ALTER TABLE foo OWNER TO postgres;  -- table owner change
SELECT relname, relkind, relowner FROM pg_class WHERE relname LIKE 'foo%';
  relname   | relkind | relowner
------------+---------+----------
 foo        | r       |        1
 foo_id_seq | S       |        1
 foo_pkey   | i       |        1
(3 rows)

ALTER TABLE foo OWNER TO mfuhr;  -- table owner change
SELECT relname, relkind, relowner FROM pg_class WHERE relname LIKE 'foo%';
  relname   | relkind | relowner
------------+---------+----------
 foo        | r       |      100
 foo_id_seq | S       |      100
 foo_pkey   | i       |      100
(3 rows)

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/