Date: Tue, 10 Nov 2020 15:09:04 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Surafel Temesgen <surafel3000@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Alvaro Herrera <alvherre@2ndquadrant.com>,
	vignesh C <vignesh21@gmail.com>,
	Justin Pryzby <pryzby@telsasoft.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
	Daniel Gustafsson <daniel@yesql.se>
Subject: Re: proposal: possibility to read dumped table's name from file
Message-ID: <20201110200904.GU16415@tamriel.snowman.net>
References: <20200903200842.GA11952@alvherre.pgsql>
 <832697.1599178532@sss.pgh.pa.us>
 <CAFj8pRBDbbmBf=eQTvpkf0=JJsG2t6qxMGPqpJRrq-M2WJQESA@mail.gmail.com>
 <CALAY4q9u30L7oGhbsfY3dPECQ8SrYa8YO=H-xOn5xWUeiEneeg@mail.gmail.com>
 <CAFj8pRCEBbB3iUqqXsj4wawjHteB2oMHRf1R4wucUzstm=fpkA@mail.gmail.com>
 <CAFj8pRCJ-F6RGmLsoO37oz75kZcwKr39c5Y4YWbd3e=nkwDOPA@mail.gmail.com>
 <CAFj8pRDCOgPLo1WNC8iniP0g6nGQdpVj-k5T3BsYrmOBtDSShw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="mYHBEULg1qMfneBr"
Content-Disposition: inline
In-Reply-To: 
 <CAFj8pRDCOgPLo1WNC8iniP0g6nGQdpVj-k5T3BsYrmOBtDSShw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--mYHBEULg1qMfneBr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Pavel Stehule (pavel.stehule@gmail.com) wrote:
> rebase + minor change - using pg_get_line_buf instead pg_get_line_append

I started looking at this and went back through the thread and while I
tend to agree that JSON may not be a good choice for this, it's not the
only possible alternative.  There is no doubt that pg_dump is already a
sophisticated data export tool, and likely to continue to gain new
features, such that having a configuration file for it would be very
handy, but this clearly isn't really going in a direction that would
allow for that.

Perhaps this feature could co-exist with a full blown configuration for
pg_dump, but even then there's certainly issues with what's proposed-
how would you handle explicitly asking for a table which is named=20
"  mytable" to be included or excluded?  Or a table which has a newline
in it?  Using a standardized format which supports the full range of
what we do in a table name, explicitly and clearly, would address these
issues and also give us the flexibility to extend the options which
could be used through the configuration file beyond just the filters in
the future.

Unlike for the pg_basebackup manifest, which we generate and read
entirely programatically, a config file for pg_dump would almost
certainly be updated manually (or, at least, parts of it would be and
perhaps other parts generated), which means it'd really be ideal to have
a proper way to support comments in it (something that the proposed
format also doesn't really get right- # must be the *first* character,
and you can only have whole-line comments..?), avoid extra unneeded
punctuation (or, at times, allow it- such as trailing commas in lists),
cleanly handle multi-line strings (consider the oft discussed idea
around having pg_dump support a WHERE clause for exporting data from
tables...), etc.

Overall, -1 from me on this approach.  Maybe it could be fixed up to
handle all the different names of objects that we support today
(something which, imv, is really a clear requirement for this feature to
be committed), but I suspect you'd end up half-way to yet another
configuration format when we could be working to support something like
TOML or maybe YAML... but if you want my 2c, TOML seems closer to what
we do for postgresql.conf and getting that over to something that's
standardized, while a crazy long shot, is a general nice idea, imv.

Thanks,

Stephen

--mYHBEULg1qMfneBr
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJfqvNfAAoJEO1sijiDR2RVutMP/RllKPstiBsuaOA7VE0bd804
AT7JFq7ex6x3FwaB5OnXBujg64zbhF0vVeEylRwvQIdwXgZ9nm8VaD4nES77rKq2
EMfXBPWN5SDx0w9iJKIgIIsI5b02ZieTLVpsq+iwAdqoE+rN5L5/rJvDoeVWOWTN
I2O/M+gY76xNNA/v3nr8t8Q1wEi0fFpZyW2ByzuS8EDs40yQ+3B9OV2MGqN7tMUt
fGh3VfIL5vesTPYgttZPm6bApE43HFVQn4ELs1rStSMIZq30xyUMT0vwIeGcns9S
6bmcO8QKU+lUL62XRki28OQzVUDOXo78u4JnY7zz21qI/8enM4Vus/+3w21zMoKl
i8bHS0HoDqaaasRX2blODY2mAe4NjhDlPrL0oG7YV/mSJpTNPmdG+btGFThWIyGe
OS4oNSSCFrran+b41aQZqdPFbTUqZ9KiRbJHi+JVURzRN0rjC7BwHSEhte7SJWBR
bOwQFEsfuby84zF4VYcpgsg112tSciElH5J/XxyL60MlvOiafCCJpgOPJSSkqRfq
r4l77H8c/+aJ+/PuPxii0xCfaVOe9JxwzAaIJ06/95aPx/IjjAmJ730kl53oQ56F
WIH45D6MFW57nY53P8otaWB+0VxeHwePzbmrgZCazmsXOb37ikeFtqNTWnE1cqZ/
WBLOL3vFx0ZVfCb/XOzb
=8rYs
-----END PGP SIGNATURE-----

--mYHBEULg1qMfneBr--