Обсуждение: Patch: forcing object owner in TOC file

Hello,

I've created small patch which allows me easily change owner during
pg_restore with backup in custom format (-Fc).
This simplifies migration when users on new server are different that
ones in backup file.

First, I get TOC file:

pg_restore -Fc -l mybackup.custom > mybackup.toc

Then, I can alter owner of any object by adding username after TOC Id,
for ex. changing this:

173; 1259 25139 TABLE public data quaker

into this:

173 quaker1; 1259 25139 TABLE public data quaker

By above line I forced quaker1 to be owner of public.data table after restore.

Then I do normal restore using modified TOC:

$ pg_restore -Fc mybackup.custom -L mybackup.toc -d quaker
pg_restore: [archiver] WARNING: altering owner for TABLE data to quaker1

and have public.data TABLE owned by quaker1 user.

Patch attached.

--
Piotr Gasidło

On 10/15/2012 07:59 AM, Piotr Gasidło wrote:
> Hello,
>
> I've created small patch which allows me easily change owner during
> pg_restore with backup in custom format (-Fc).
> This simplifies migration when users on new server are different that
> ones in backup file.
>
> First, I get TOC file:
>
> pg_restore -Fc -l mybackup.custom > mybackup.toc
>
> Then, I can alter owner of any object by adding username after TOC Id,
> for ex. changing this:
>
> 173; 1259 25139 TABLE public data quaker
>
> into this:
>
> 173 quaker1; 1259 25139 TABLE public data quaker
>
> By above line I forced quaker1 to be owner of public.data table after restore.
>
> Then I do normal restore using modified TOC:
>
> $ pg_restore -Fc mybackup.custom -L mybackup.toc -d quaker
> pg_restore: [archiver] WARNING: altering owner for TABLE data to quaker1
>
> and have public.data TABLE owned by quaker1 user.



Sorry, but this doesn't strike me as a very good idea at all. Why not
just alter the table ownership after the restore is done? If we start
allowing stuff other than the TOC ID to be specified in the list file
the modifications will never end. And if we do want to do that then it
needs to be designed properly. For example, one change that seems far
more important to me than changing the owner is to provide for restoring
stuff to a different schema.

BTW, I realize your patch is small, but it's usually a good idea to
discuss an idea on the mailing list before sending in a patch.

cheers

andrew

2012/10/15 Andrew Dunstan <andrew@dunslane.net>:
> Sorry, but this doesn't strike me as a very good idea at all. Why not just
> alter the table ownership after the restore is done?

Yes, I could restore, wrote later ALTER ... OWNER TO ... - but this
method allowed me to do it quicker.

> If we start allowing
> stuff other than the TOC ID to be specified in the list file the
> modifications will never end.

Understood, sounds reasonably.

> BTW, I realize your patch is small, but it's usually a good idea to discuss
> an idea on the mailing list before sending in a patch.

I've new here, next time I will send idea and wait for response before
sending any patch.

--
Piotr Gasidło