Re: Detect supported SET parameters when pg_restore is run

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Detect supported SET parameters when pg_restore is run
Date: 2016-09-27 21:12:32
Message-ID: 2739.1475010752@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2016-09-27 21:12:38 Re: Fix checkpoint skip logic on idle systems by tracking LSN progress
Previous Message Tom Lane 2016-09-27 21:01:03 Re: to_date_valid()