MIME-Version: 1.0
From: Shin Berg <sjh910805@gmail.com>
Date: Sat, 14 Feb 2026 17:48:11 +0900
Message-ID: <CACSdjfMWcR7aJUDf6XNt_yaDi+riz3Ku4EQ-x3xA=Xx1209n2g@mail.gmail.com>
Subject: Inconsistency in owner assignment between INDEX and STATISTICS
To: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000c44c99064ac4c83b"
Archived-At: <https://www.postgresql.org/message-id/CACSdjfMWcR7aJUDf6XNt_yaDi%2Briz3Ku4EQ-x3xA%3DXx1209n2g%40mail.gmail.com>
Precedence: bulk

--000000000000c44c99064ac4c83b
Content-Type: text/plain; charset="UTF-8"

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.

--000000000000c44c99064ac4c83b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>I&#39;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.<br><br>Current behavior (tested =
on REL_17_STABLE):<br><br>- When a superuser creates an INDEX on another us=
er&#39;s table, the index is owned by the *table owner* (see catalog/index.=
c: index relation&#39;s relowner is set from the heap relation&#39;s relown=
er).<br>- When a superuser creates STATISTICS on another user&#39;s table, =
the statistics object is owned by the *current user* (statscmds.c: stxowner=
 =3D GetUserId()).<br><br>So in a scenario where a DBA creates both an inde=
x and extended statistics on a user&#39;s table, the table owner can DROP t=
he index (because they own it) but cannot DROP the statistics object (they =
get &quot;does not exist&quot; 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 re=
solve dependency issues before altering the table).<br><br>Reproduction (as=
 superuser, then as table owner):<br><br>=C2=A0 CREATE SCHEMA shared_schema=
;<br>=C2=A0 CREATE USER bob;<br>=C2=A0 GRANT USAGE, CREATE ON SCHEMA shared=
_schema TO bob;<br><br>=C2=A0 SET ROLE bob;<br>=C2=A0 CREATE TABLE shared_s=
chema.bob_table (a int, b int);<br>=C2=A0 RESET ROLE;<br><br>=C2=A0 CREATE =
INDEX idx_bob ON shared_schema.bob_table(a);<br>=C2=A0 CREATE STATISTICS st=
at_bob ON a, b FROM shared_schema.bob_table;<br><br>=C2=A0 SELECT &#39;INDE=
X&#39;, c.relname, pg_get_userbyid(c.relowner) FROM pg_index i<br>=C2=A0 =
=C2=A0 JOIN pg_class c ON c.oid =3D i.indexrelid<br>=C2=A0 =C2=A0 WHERE ind=
relid =3D &#39;shared_schema.bob_table&#39;::regclass<br>=C2=A0 UNION ALL<b=
r>=C2=A0 SELECT &#39;STATISTICS&#39;, stxname, pg_get_userbyid(stxowner) FR=
OM pg_statistic_ext<br>=C2=A0 =C2=A0 WHERE stxrelid =3D &#39;shared_schema.=
bob_table&#39;::regclass;<br>=C2=A0 -- INDEX owner =3D bob, STATISTICS owne=
r =3D superuser<br><br>=C2=A0 SET ROLE bob;<br>=C2=A0 DROP INDEX shared_sch=
ema.idx_bob; =C2=A0 =C2=A0 =C2=A0 =C2=A0-- succeeds<br>=C2=A0 DROP STATISTI=
CS shared_schema.stat_bob; =C2=A0-- ERROR: statistics object &quot;...&quot=
; does not exist<br><br>I&#39;m not sure if the current STATISTICS ownershi=
p behavior was intentional. If it wasn&#39;t, would it make sense to assign=
 the statistics object&#39;s owner to the relation owner (same as INDEX) fo=
r consistency and to avoid the above scenario?<br><br>Thanks for your time.=
</div>

--000000000000c44c99064ac4c83b--