Re: pg_restore -L reordering of the statements does not work

Thanks a lot Tom and Andres. Can you please guide me what is the
recommended steps?

On Wed, 15 Nov 2023 at 04:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2023-11-14 17:40:02 -0500, Tom Lane wrote:
> >> ... no, it should be for the user executing the ALTER to have
> permission.
>
> > That check succeed - what fails is a check on the new owner of the
> table. See
> > tablecmds.c ATExecChangeOwner:
>
> > /* New owner must have CREATE privilege on namespace */
> > aclresult = object_aclcheck(NamespaceRelationId,
> namespaceOid, newOwnerId,
> > ACL_CREATE);
>
> Oh! I was just thinking about the initial object-lookup check,
> I'd forgotten about the one in the ALTER OWNER code itself.
>
> Hm. The intent of that check is to ensure that the ALTER doesn't
> produce a situation that the object-recipient user couldn't have
> created by himself. But I wonder if that's too narrow-minded, and
> we should craft a new rule that allows things dependent on only the
> calling user's permissions. Maybe allow if either the calling user or
> the recipient has CREATE on the schema? Or allow if calling user has
> ownership on the schema (implying that he could temporarily GRANT the
> necessary rights and then undo it)? Either of those would legitimize
> what pg_dump wants to do.
>
> This is getting way off-topic for pgsql-admin, btw.
>
> regards, tom lane
>