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

Malcolm Locke <malc(at)wholemeal(dot)co(dot)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