pg_dump reporing version of server & pg_dump as comments in the output

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

Responses

Browse pgsql-hackers by date

  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?