Gentle ping on this thread — any thoughts or concerns about the
proposed alignment?

Thanks.

On Sat, Feb 14, 2026 at 5:48 PM Shin Berg <[email protected]> wrote:

> Hi,
>
> I'd like to raise a small consistency issue between how INDEX and extended
> STATISTICS handle object ownership, and ask whether aligning them would be
> desirable.
>
> Current behavior (tested on REL_17_STABLE):
>
> - When a superuser creates an INDEX on another user's table, the index is
> owned by the *table owner* (see catalog/index.c: index relation's relowner
> is set from the heap relation's relowner).
> - When a superuser creates STATISTICS on another user's table, the
> statistics object is owned by the *current user* (statscmds.c: stxowner =
> GetUserId()).
>
> So in a scenario where a DBA creates both an index and extended statistics
> on a user's table, the table owner can DROP the index (because they own it)
> but cannot DROP the statistics object (they get "does not exist" when
> lacking ownership, which hides the real permission issue). That can cause
> operational friction in multi-tenant or shared-schema setups (e.g. the
> table owner cannot drop the statistics to resolve dependency issues before
> altering the table).
>
> Reproduction (as superuser, then as table owner):
>
>   CREATE SCHEMA shared_schema;
>   CREATE USER bob;
>   GRANT USAGE, CREATE ON SCHEMA shared_schema TO bob;
>
>   SET ROLE bob;
>   CREATE TABLE shared_schema.bob_table (a int, b int);
>   RESET ROLE;
>
>   CREATE INDEX idx_bob ON shared_schema.bob_table(a);
>   CREATE STATISTICS stat_bob ON a, b FROM shared_schema.bob_table;
>
>   SELECT 'INDEX', c.relname, pg_get_userbyid(c.relowner) FROM pg_index i
>     JOIN pg_class c ON c.oid = i.indexrelid
>     WHERE indrelid = 'shared_schema.bob_table'::regclass
>   UNION ALL
>   SELECT 'STATISTICS', stxname, pg_get_userbyid(stxowner) FROM
> pg_statistic_ext
>     WHERE stxrelid = 'shared_schema.bob_table'::regclass;
>   -- INDEX owner = bob, STATISTICS owner = superuser
>
>   SET ROLE bob;
>   DROP INDEX shared_schema.idx_bob;        -- succeeds
>   DROP STATISTICS shared_schema.stat_bob;  -- ERROR: statistics object
> "..." does not exist
>
> I'm not sure if the current STATISTICS ownership behavior was intentional.
> If it wasn't, would it make sense to assign the statistics object's owner
> to the relation owner (same as INDEX) for consistency and to avoid the
> above scenario?
>
> Thanks for your time.
>

Reply via email to