Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-11-07 Thread Peter Eisentraut
On 9/27/16 6:57 PM, Vitaly Burovoy wrote: > On 9/27/16, Vitaly Burovoy wrote: >> On 9/27/16, Tom Lane 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

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-27 Thread Pavel Stehule
2016-09-27 23:12 GMT+02:00 Tom Lane : > Vitaly Burovoy writes: > > On 9/27/16, Tom Lane wrote: > >> I'm not exactly convinced that you did. There's only one copy of > >> Archive->remoteVersion, and you're overwriting it long

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-27 Thread Vitaly Burovoy
On 9/27/16, Vitaly Burovoy wrote: > On 9/27/16, Tom Lane 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

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-27 Thread Vitaly Burovoy
On 9/27/16, Tom Lane wrote: > Vitaly Burovoy writes: >> On 9/27/16, Tom Lane 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 >>>

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-27 Thread Tom Lane
Vitaly Burovoy writes: > On 9/27/16, Tom Lane 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

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-27 Thread Vitaly Burovoy
On 9/27/16, Tom Lane wrote: > Vitaly Burovoy writes: >> On 9/27/16, Tom Lane wrote: >>> The general policy has always been that pg_dump output is only expected >>> to >>> restore without errors into a server that's the same or

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-27 Thread Tom Lane
Vitaly Burovoy writes: > On 9/27/16, Tom Lane wrote: >> The general policy has always been that pg_dump output is only expected to >> restore without errors into a server that's the same or newer version as >> pg_dump (regardless of the server

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-27 Thread Vitaly Burovoy
On 9/27/16, Tom Lane wrote: > Robert Haas writes: >> On Mon, Sep 26, 2016 at 9:56 PM, Vitaly Burovoy >> wrote: >>> We do dump/restore schemas/data via custom/dir formats and we have to >>> keep several client versions for 9.2,

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-27 Thread Tom Lane
Robert Haas writes: > On Mon, Sep 26, 2016 at 9:56 PM, Vitaly Burovoy > wrote: >> We do dump/restore schemas/data via custom/dir formats and we have to >> keep several client versions for 9.2, 9.4 and 9.5 versions on local >> workstations because

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-27 Thread Robert Haas
On Mon, Sep 26, 2016 at 9:56 PM, Vitaly Burovoy wrote: > At work we use several major versions of PostgreSQL, and developers > use non-local clusters for developing and debugging. > We do dump/restore schemas/data via custom/dir formats and we have to > keep several

[HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-26 Thread Vitaly Burovoy
Hackers, At work we use several major versions of PostgreSQL, and developers use non-local clusters for developing and debugging. We do dump/restore schemas/data via custom/dir formats and we have to keep several client versions for 9.2, 9.4 and 9.5 versions on local workstations because after