From: | "Wang, Jing" <jingw(at)fast(dot)au(dot)fujitsu(dot)com> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | pg_dump reporing version of server & pg_dump as comments in the output |
Date: | 2014-02-28 00:10:55 |
Message-ID: | F40B0968DB0A904DA78A924E633BE7863C25F6@SYDEXCHTMP2.au.fjanz.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Enclosed is the patch to implement the requirement that pg_dump should
report version of server & pg_dump as comments in the output.
[Benefit]
By running "head" on pg_dump output, you can readily discover what
version of PostgreSQL was used to generate that dump. Very useful
especially for "mouldy old database dumps."
The benefit of this requirement is to let user clearly understand from
which version the dump output file will be insert into which version
database server and easy handle the problems of Incompatibility
versions.
[Analysis]
Using pg_dump can dump the data into the file with format set to be
'c','t' or plain text. In the existing version the version of server &
pg_dump is already there when the format of file is 'c' or 't'. And even
for the plain text format file the version of server & pg_dump is
already there if using '--verbose' in pg_dump. Using '--verbose' leads
to some many other prints which are not required always.
So the requirement is dump the version of server & pg_dump as comment
into the plain text format output file even without using '--verbose'
option.
[Solution details]
The main change is in the pg_backup_archiver.c file, in the function
'RestoreArchive' the version of server & pg_dump is only print when
finding the '--verbose' option to be used in current version. Now we
just let the printing works even without finding the '--verbose' option.
[what is changed when applying the patch]
1. The output file which is created by pg_dump with format set to be
'plain text' and without using '--verbose' option will include the
version of server & pg_dump. One example is as following:
--
-- PostgreSQL database dump
--
-- Dumped from database version 9.2.4
-- Dumped by pg_dump version 9.4devel
SET statement_timeout = 0;
SET lock_timeout = 0;
SET client_encoding = 'UTF8';
...
2. The output file which is created by pg_dumpall with format set to be
'plain text' and without using '--verbose' option will include the
version of server & pg_dump. The example is as following:
--
-- PostgreSQL database cluster dump
--
SET default_transaction_read_only = off;
...
\connect connectdb
SET default_transaction_read_only = off;
--
-- PostgreSQL database dump
--
-- Dumped from database version 9.2.4
-- Dumped by pg_dump version 9.4devel
SET statement_timeout = 0;
SET lock_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
...
\connect postgres
SET default_transaction_read_only = off;
--
-- PostgreSQL database dump
--
-- Dumped from database version 9.2.4
-- Dumped by pg_dump version 9.4devel
SET statement_timeout = 0;
SET lock_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SET check_function_bodies = false;
3. The version of server and pg_dump will be dumped into the output
file. The output file is created by the following command:
pg_restore inputFile -f output.sql
One example is as following:
--
-- PostgreSQL database dump
--
-- Dumped from database version 9.2.4
-- Dumped by pg_dump version 9.4devel
SET statement_timeout = 0;
SET lock_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
...
Kind regards
Jing
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-02-28 00:14:13 | Windows exit code 128 ... it's baaack |
Previous Message | Greg Stark | 2014-02-27 23:41:08 | Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem? |