Thread: [HACKERS] proposal - pg_dump: flag to suppress output of SQL comments

[HACKERS] proposal - pg_dump: flag to suppress output of SQL comments

From
Malcolm Locke
Date:
Hello Hackers,

Would a patch to add a flag to pg_dump to suppress the output of SQL
comments be likely to be accepted?


So for example `pg_dump`:
 -- -- Name: foos; Type: TABLE; Schema: public; Owner: - --
 CREATE TABLE foos ( ...


With `pg_dump --no-sql-comments` Would become:
 CREATE TABLE foos ( ...


The rationale behind this is that we use schema dumps committed to VCS
to ensure database structures are synchronised among teams of
developers.

The SQL generated by pg_dump seems to be fairly constant between
Postgres versions, however the structure of the SQL comments in the
dumps changes quite frequently between Postgres versions.  This creates
a lot of churn on these structure files, unrelated to actual changes in
the database structure, in our VCS when developers are using different
versions of Postgres.  Note this is all via Ruby on Rails so we are not
the only users affected.

We could strip comments after the dump has been generated but this is
not ideal as without parsing the dump file we can't know if a line
beginning with -- is a comment or a string literal.

I'm happy to have a crack at a patch to pg_dump if it would be likely to
be accepted.

Cheers,

Malc


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal - pg_dump: flag to suppress output of SQL comments

From
Tom Lane
Date:
Malcolm Locke <malc@wholemeal.co.nz> writes:
> Would a patch to add a flag to pg_dump to suppress the output of SQL
> comments be likely to be accepted?

Not unless you can come up with a better rationale than this:

> The SQL generated by pg_dump seems to be fairly constant between
> Postgres versions, however the structure of the SQL comments in the
> dumps changes quite frequently between Postgres versions.  This creates
> a lot of churn on these structure files, unrelated to actual changes in
> the database structure, in our VCS when developers are using different
> versions of Postgres.

That seems like complete nonsense; we don't change the comments more
frequently than other aspects of pg_dump's output, in fact probably
much less often.

Just to make sure I'm not totally mistaken about this, I diffed the
results from pg_dump 9.2 through HEAD dumping the same 9.2 database.
I do see a couple of rounds of comment changes, but there are also two
different rounds of changes in dump order, a round of changes in layout
of view/rule reverse-compilations, a round of changes in the
schema-qualification of ALTER TYPE OWNER commands, multiple changes in
the dump header (particularly the collection of SET commands there), and
assorted changes in minor details of syntax.  And the particular test
database I was using (the 9.2 regression database) doesn't even trigger
some other changes that have been made, such as how to break circular
dependencies involving views.  We're not going to introduce
backwards-compatibility options for that sort of stuff (I hope), so
I do not think that a switch of this sort is really going to produce
the end result you're wishing for.

You might be able to standardize things a bit better if you could get
all your developers to use the same late-model version of pg_dump
while producing output to go into the VCS.  That won't be a 100%
solution, because some of the version-specific output is generated
on the backend side, but I bet it would improve matters a lot.
        regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers