Re: Detect supported SET parameters when pg_restore is run

On 9/27/16 6:57 PM, Vitaly Burovoy wrote:
> On 9/27/16, Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com> wrote:
>> On 9/27/16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> (The other thing I'd want here is a --target-version option so that
>>> you could get the same output alterations in pg_dump or pg_restore to
>>> text. Otherwise it's nigh undebuggable, and certainly much harder
>>> to test than it needs to be.)
>>
>> I thought that way. I'm ready to introduce that parameter, but again,
>> I see now it will influence only SET parameters. Does it worth it?
>
> The only reason I have not implemented it was attempt to avoid users
> being confused who could think that result of pg_dump (we need it
> there for the plain text output) or pg_restore can be converted for
> target version to be restored without new features (but now it is
> wrong).

I'm in favor of making this work. But I also agree with the earlier
commenters that we shouldn't overload remoteVersion to mean sometimes
source and sometimes target version. It would probably be enough for
now to leave remoteVersion to mean source version, introduce a new field
targetVersion, default that to remoteVersion in plain text format, and
set it to the actual remote version when restoring directly to a
database. It will need a bit of work to tie it all together, but it
shouldn't be too difficult.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services