Re: Detect supported SET parameters when pg_restore is run

2016-09-27 23:12 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com> writes:
> > On 9/27/16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> I'm not exactly convinced that you did. There's only one copy of
> >> Archive->remoteVersion, and you're overwriting it long before the
> >> dump process is over.
>
> > It does not seem that I'm "overwriting it long before the dump process
> > is over"...
>
> There's a lot that happens during RestoreArchive. Even if none of it
> inspects remoteVersion today, I do not think that's a safe assumption to
> make going forward. The easiest counterexample is that this very bit of
> code you want to add does so. I really do not want to get into a design
> that says "remoteVersion means the source server version until we reach
> RestoreArchive, and the target version afterwards". That way madness
> lies. If we're going to try altering the emitted SQL based on target
> version, let's first create a separation between those concepts; otherwise
> I will bet that we add more bugs than we remove.
>
> (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.)
>

This options likes like very good idea.

Regards

Pavel

>
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>