Re: pg_dump fails to set index ownership

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/