MIME-Version: 1.0
References: <CACSdjfMWcR7aJUDf6XNt_yaDi+riz3Ku4EQ-x3xA=Xx1209n2g@mail.gmail.com>
In-Reply-To: <CACSdjfMWcR7aJUDf6XNt_yaDi+riz3Ku4EQ-x3xA=Xx1209n2g@mail.gmail.com>
From: Shin Berg <sjh910805@gmail.com>
Date: Thu, 26 Feb 2026 18:52:38 +0900
Message-ID: <CACSdjfPuNND8dn8zYame6mRwoDPKxMKRQvih=W1Nrq5urvwTsg@mail.gmail.com>
Subject: Re: Inconsistency in owner assignment between INDEX and STATISTICS
To: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000005a0aca064bb71580"
Archived-At: <https://www.postgresql.org/message-id/CACSdjfPuNND8dn8zYame6mRwoDPKxMKRQvih%3DW1Nrq5urvwTsg%40mail.gmail.com>
Precedence: bulk

--0000000000005a0aca064bb71580
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Gentle ping on this thread =E2=80=94 any thoughts or concerns about the
proposed alignment?

Thanks.

On Sat, Feb 14, 2026 at 5:48=E2=80=AFPM Shin Berg <sjh910805@gmail.com> wro=
te:

> Hi,
>
> I'd like to raise a small consistency issue between how INDEX and extende=
d
> STATISTICS handle object ownership, and ask whether aligning them would b=
e
> 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 relowne=
r
> 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 =
=3D
> GetUserId()).
>
> So in a scenario where a DBA creates both an index and extended statistic=
s
> on a user's table, the table owner can DROP the index (because they own i=
t)
> 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 befor=
e
> 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 =3D i.indexrelid
>     WHERE indrelid =3D 'shared_schema.bob_table'::regclass
>   UNION ALL
>   SELECT 'STATISTICS', stxname, pg_get_userbyid(stxowner) FROM
> pg_statistic_ext
>     WHERE stxrelid =3D 'shared_schema.bob_table'::regclass;
>   -- INDEX owner =3D bob, STATISTICS owner =3D 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.
>

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

<div dir=3D"ltr">Gentle ping on this thread =E2=80=94 any thoughts or conce=
rns about the<br>proposed alignment?<br><br>Thanks.</div><br><div class=3D"=
gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Sat, Feb 14, 2026 at 5:48=E2=80=AFPM Shin Berg &lt;<a href=3D"mailto:sjh91=
0805@gmail.com">sjh910805@gmail.com</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi,<br><br>I&#39;d like=
 to raise a small consistency issue between how INDEX and extended STATISTI=
CS handle object ownership, and ask whether aligning them would be desirabl=
e.<br><br>Current behavior (tested on REL_17_STABLE):<br><br>- When a super=
user creates an INDEX on another user&#39;s table, the index is owned by th=
e *table owner* (see catalog/index.c: index relation&#39;s relowner is set =
from the heap relation&#39;s relowner).<br>- When a superuser creates STATI=
STICS on another user&#39;s table, the statistics object is owned by the *c=
urrent user* (statscmds.c: stxowner =3D GetUserId()).<br><br>So in a scenar=
io where a DBA creates both an index and extended statistics on a user&#39;=
s table, the table owner can DROP the index (because they own it) but canno=
t DROP the statistics object (they get &quot;does not exist&quot; when lack=
ing ownership, which hides the real permission issue). That can cause opera=
tional friction in multi-tenant or shared-schema setups (e.g. the table own=
er cannot drop the statistics to resolve 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 G=
RANT USAGE, CREATE ON SCHEMA shared_schema TO bob;<br><br>=C2=A0 SET ROLE b=
ob;<br>=C2=A0 CREATE TABLE shared_schema.bob_table (a int, b int);<br>=C2=
=A0 RESET ROLE;<br><br>=C2=A0 CREATE INDEX idx_bob ON shared_schema.bob_tab=
le(a);<br>=C2=A0 CREATE STATISTICS stat_bob ON a, b FROM shared_schema.bob_=
table;<br><br>=C2=A0 SELECT &#39;INDEX&#39;, c.relname, pg_get_userbyid(c.r=
elowner) FROM pg_index i<br>=C2=A0 =C2=A0 JOIN pg_class c ON c.oid =3D i.in=
dexrelid<br>=C2=A0 =C2=A0 WHERE indrelid =3D &#39;shared_schema.bob_table&#=
39;::regclass<br>=C2=A0 UNION ALL<br>=C2=A0 SELECT &#39;STATISTICS&#39;, st=
xname, pg_get_userbyid(stxowner) FROM pg_statistic_ext<br>=C2=A0 =C2=A0 WHE=
RE stxrelid =3D &#39;shared_schema.bob_table&#39;::regclass;<br>=C2=A0 -- I=
NDEX owner =3D bob, STATISTICS owner =3D superuser<br><br>=C2=A0 SET ROLE b=
ob;<br>=C2=A0 DROP INDEX shared_schema.idx_bob; =C2=A0 =C2=A0 =C2=A0 =C2=A0=
-- succeeds<br>=C2=A0 DROP STATISTICS shared_schema.stat_bob; =C2=A0-- ERRO=
R: statistics object &quot;...&quot; does not exist<br><br>I&#39;m not sure=
 if the current STATISTICS ownership behavior was intentional. If it wasn&#=
39;t, would it make sense to assign the statistics object&#39;s owner to th=
e relation owner (same as INDEX) for consistency and to avoid the above sce=
nario?<br><br>Thanks for your time.</div>
</blockquote></div>

--0000000000005a0aca064bb71580--