public inbox for [email protected]  

help / color / mirror / Atom feed

From: Shin Berg <[email protected]>
To: [email protected]
Subject: Re: Inconsistency in owner assignment between INDEX and STATISTICS
Date: Thu, 26 Feb 2026 18:52:38 +0900
Message-ID: <CACSdjfPuNND8dn8zYame6mRwoDPKxMKRQvih=W1Nrq5urvwTsg@mail.gmail.com> (raw)
In-Reply-To: <CACSdjfMWcR7aJUDf6XNt_yaDi+riz3Ku4EQ-x3xA=Xx1209n2g@mail.gmail.com>
References: <CACSdjfMWcR7aJUDf6XNt_yaDi+riz3Ku4EQ-x3xA=Xx1209n2g@mail.gmail.com>

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.
>

view thread (7+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Inconsistency in owner assignment between INDEX and STATISTICS
  In-Reply-To: <CACSdjfPuNND8dn8zYame6mRwoDPKxMKRQvih=W1Nrq5urvwTsg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox