MIME-Version: 1.0
References: 
 <CACSdjfMWcR7aJUDf6XNt_yaDi+riz3Ku4EQ-x3xA=Xx1209n2g@mail.gmail.com>
 <CAJ3gD9eJE_c=eSbBjqAAg+-x2XOSgZ5uYqyAiy4TrJJwxEXyng@mail.gmail.com>
In-Reply-To: 
 <CAJ3gD9eJE_c=eSbBjqAAg+-x2XOSgZ5uYqyAiy4TrJJwxEXyng@mail.gmail.com>
From: Shin Berg <sjh910805@gmail.com>
Date: Wed, 11 Mar 2026 18:54:01 +0900
Message-ID: 
 <CACSdjfPor9NRN4WiNZ5HmpdFn7q6dERHuZvaMxHMirXUYDC6_A@mail.gmail.com>
Subject: Re: Inconsistency in owner assignment between INDEX and STATISTICS
To: Amit Khandekar <amitdkhan.pg@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000004563d4064cbc9ee1"
Archived-At: 
 <https://www.postgresql.org/message-id/CACSdjfPor9NRN4WiNZ5HmpdFn7q6dERHuZvaMxHMirXUYDC6_A%40mail.gmail.com>
Precedence: bulk

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

Thank you for the detailed feedback, Amit.

You're right on both points. I had been comparing STATISTICS against INDEX
and treating the difference as an inconsistency, but as you point out,
INDEX ownership is special =E2=80=94 it's tied to the table and intentional=
ly not
user-adjustable. STATISTICS follows the same ownership model as VIEW (the
creator becomes the owner), which is consistent and by design.

I also verified locally that my reproduction script was flawed: the
"must be owner" error was caused by a schema search path issue, not an
ownership restriction. The script did not demonstrate what I claimed.

I'm withdrawing this proposal. Thanks again for taking the time to review
it.

On Tue, Mar 10, 2026 at 11:07=E2=80=AFPM Amit Khandekar <amitdkhan.pg@gmail=
.com>
wrote:

> On Sat, 14 Feb 2026 at 14:18, Shin Berg <sjh910805@gmail.com> wrote:
> >
> > Hi,
> >
> > I'd like to raise a small consistency issue between how INDEX and
> extended STATISTICS handle object ownership, and ask whether aligning the=
m
> 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 =
=3D
> GetUserId()).
>
> I will try to divide the problem into two questions:
>
> 1. Should the statistics object's owner be permanently associated with
> the table owner?
>
> From the docs, it does look like the current behaviour is intentional.
>
> https://www.postgresql.org/docs/current/sql-createstatistics.html :
> "You must be the owner of a table to create a statistics object
> reading it. Once created, however, the ownership of the statistics
> object is independent of the underlying table(s)."
>
> So I think we should not change the behaviour where the statistics
> object is created with independent ownership.
>
> With indexes, the behaviour has always been that it is associated with
> the table:
>
> postgres=3D# alter INDEX shared_schema.idx_bob owner to bob1;
> WARNING:  cannot change owner of index "idx_bob"
> HINT:  Change the ownership of the index's table instead.
>
> 2. Regardless of that, should the "create statistics" create the stat
> object with the same ownership as the table's, if it's the superuser
> who is creating the statistics?
>
> I think, since there is no permanent association of ownership between
> the table and the statistics, it makes sense for the user who is
> running the create command to own the statistics, regardless of who
> the user is, provided that the user has privileges.
>
> >
> > 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).
>
> The permission error should be emitted if the DROP is on the right
> schema. See below.
>
> > 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).
>
> Maybe, make sure the table owner (and not the superuser) is creating
> the statistics?
>
> >
> > 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
>
> The statistics object is created in the default schema, not the table's
> schema.
> postgres=3D>   DROP STATISTICS public.stat_bob;
> ERROR:  must be owner of statistics object public.stat_bob
>
> Thanks
> -Amit Khandekar
>

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

<div dir=3D"ltr"><div dir=3D"ltr">Thank you for the detailed feedback, Amit=
.<br><br>You&#39;re right on both points. I had been comparing STATISTICS a=
gainst INDEX<br>and treating the difference as an inconsistency, but as you=
 point out,<br>INDEX ownership is special =E2=80=94 it&#39;s tied to the ta=
ble and intentionally not<br>user-adjustable. STATISTICS follows the same o=
wnership model as VIEW (the<br>creator becomes the owner), which is consist=
ent and by design.<br><br>I also verified locally that my reproduction scri=
pt was flawed: the<br>&quot;must be owner&quot; error was caused by a schem=
a search path issue, not an<br>ownership restriction. The script did not de=
monstrate what I claimed.<br><br>I&#39;m withdrawing this proposal. Thanks =
again for taking the time to review it.</div><br><div class=3D"gmail_quote =
gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar 10=
, 2026 at 11:07=E2=80=AFPM Amit Khandekar &lt;<a href=3D"mailto:amitdkhan.p=
g@gmail.com">amitdkhan.pg@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">On Sat, 14 Feb 2026 at 14:18, Shin Berg =
&lt;<a href=3D"mailto:sjh910805@gmail.com" target=3D"_blank">sjh910805@gmai=
l.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; 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>
&gt;<br>
&gt; Current behavior (tested on REL_17_STABLE):<br>
&gt;<br>
&gt; - When a superuser creates an INDEX on another user&#39;s table, the i=
ndex is owned by the *table owner* (see catalog/index.c: index relation&#39=
;s relowner is set from the heap relation&#39;s relowner).<br>
&gt; - 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>
I will try to divide the problem into two questions:<br>
<br>
1. Should the statistics object&#39;s owner be permanently associated with<=
br>
the table owner?<br>
<br>