pgsql: test_pg_dump TAP test whitespace cleanup

Stephen Frost wrote:

test_pg_dump TAP test whitespace cleanup

The formatting of the perl hashes used in the TAP tests for test_pg_dump
was rather horribly inconsistent and made it more difficult than it
really should have been to add new tests or adjust what tests are for
what runs, etc.

Reformat to clean that all up.

Whitespace-only changes.

This will be undone by the next perltidy run.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:

Stephen Frost wrote:

test_pg_dump TAP test whitespace cleanup

The formatting of the perl hashes used in the TAP tests for test_pg_dump
was rather horribly inconsistent and made it more difficult than it
really should have been to add new tests or adjust what tests are for
what runs, etc.

Reformat to clean that all up.

Whitespace-only changes.

This will be undone by the next perltidy run.

Ugh.

I certainly hope what was there before wasn't the result of a perltidy
run as it was quite ugly and inconsistent..

Thanks!

Stephen

Stephen Frost wrote:

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:

This will be undone by the next perltidy run.

Ugh.

I certainly hope what was there before wasn't the result of a perltidy
run as it was quite ugly and inconsistent..

Maybe it was. I checked the diff after running perltidy after your
commit and there are some changes that look like a reversion of your
changes, but I don't know if there are other changes.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:

Stephen Frost wrote:

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:

This will be undone by the next perltidy run.

Ugh.

I certainly hope what was there before wasn't the result of a perltidy
run as it was quite ugly and inconsistent..

Maybe it was. I checked the diff after running perltidy after your
commit and there are some changes that look like a reversion of your
changes, but I don't know if there are other changes.

Yeah, I took a look at what perltidy is doing and at least some of that
was stuff I went through and fixed.

The changes to the %tests structure are pretty reasonable and it looks
like it's going to preserve at least some of what I did there because it
doesn't (always, at least) re-combine lines that have been split.
Unfortunately, what's it's doing to the %pgdump_runs structure are
rather annoying because it wants to turn something like:

- column_inserts => {
- dump_cmd => [
- 'pg_dump',
- '-f', "$tempdir/column_inserts.sql",
- '-a',
- '--column-inserts',
- 'postgres',
- ], },

into:

+    column_inserts => {
+        dump_cmd => [
+            'pg_dump',                     '-f',
+            "$tempdir/column_inserts.sql", '-a',
+            '--column-inserts',            'postgres',
+        ],
+    },

I don't mind the change in indentation, of course, but obviously it's a
lot nicer when the '-f $tempdir/column_insert.sql' is all on the same
line since that's clearly a flag with an argument.

I could change all of those to be long versions, eg "--file=blah", to
keep them together. Not really ideal, but I'm not really worried that
getopt() is going to break either.

Unless anyone has a better idea, I'll see about doing that, and then
run perltidy of it to clean it up.

Thanks!

Stephen

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:

Stephen Frost wrote:

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:

This will be undone by the next perltidy run.

Ugh.

I certainly hope what was there before wasn't the result of a perltidy
run as it was quite ugly and inconsistent..

Maybe it was. I checked the diff after running perltidy after your
commit and there are some changes that look like a reversion of your
changes, but I don't know if there are other changes.

Uh, after finding our perltidyrc and running with that, I have to ask,
why are we setting vertical-tightness to 2 (never break before a closing
token)? The default of 0 (always break) end up being a lot nicer when
working on lists. Stacking isolated opening/closing tokens does make
sense, to me, at least. Then again, I guess those might screw up other
bits of code. :/

Sigh.

Thanks!

Stephen

Stephen Frost wrote:

Uh, after finding our perltidyrc and running with that, I have to ask,
why are we setting vertical-tightness to 2 (never break before a closing
token)? The default of 0 (always break) end up being a lot nicer when
working on lists. Stacking isolated opening/closing tokens does make
sense, to me, at least. Then again, I guess those might screw up other
bits of code. :/

I think it's mostly a matter of personal preference among the (small
group of) people who first set up the perltidy args -- see the thread
around here:
/messages/by-id/20120616024516.GC26006@momjian.us

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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