Re: Patch: forcing object owner in TOC file - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Patch: forcing object owner in TOC file
Date
Msg-id 507C0409.2010901@dunslane.net
Whole thread Raw
In response to Patch: forcing object owner in TOC file  (Piotr Gasidło <quaker@barbara.eu.org>)
Responses Re: Patch: forcing object owner in TOC file  (Piotr Gasidło <quaker@barbara.eu.org>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal - assign result of query to psql variable
Next
From: Simon Riggs
Date:
Subject: Re: Deprecating RULES