Subject: Re: proposal: possibility to read dumped table's name from file
To: Stephen Frost <sfrost@snowman.net>, Daniel Gustafsson <daniel@yesql.se>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
 Dean Rasheed <dean.a.rasheed@gmail.com>, Justin Pryzby
 <pryzby@telsasoft.com>, Pavel Stehule <pavel.stehule@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
 Surafel Temesgen <surafel3000@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 vignesh C <vignesh21@gmail.com>
References: <202107122259.n6o5uwb5erza@alvherre.pgsql>
 <3183720.1626131795@sss.pgh.pa.us>
 <20210713134013.GF20766@tamriel.snowman.net>
 <2caf1efb-359d-7720-9d6e-88efdaaf55dd@enterprisedb.com>
 <0CDB1A7D-F3FB-4689-B452-9E95A8DC6B8C@yesql.se>
 <CAOuzzgo=jCedUd9imehf+DtWPaHXG0K4JVDswJ35Yt=MZTkweQ@mail.gmail.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
Message-ID: <a4c645f0-85ef-1374-41db-d42ba8fd0549@enterprisedb.com>
Date: Tue, 13 Jul 2021 23:57:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
 <CAOuzzgo=jCedUd9imehf+DtWPaHXG0K4JVDswJ35Yt=MZTkweQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/a4c645f0-85ef-1374-41db-d42ba8fd0549%40enterprisedb.com>
Precedence: bulk

On 7/13/21 10:55 PM, Stephen Frost wrote:
> Greetings,
> 
> On Tue, Jul 13, 2021 at 16:44 Daniel Gustafsson <daniel@yesql.se 
> <mailto:daniel@yesql.se>> wrote:
> 
>      > On 13 Jul 2021, at 18:14, Tomas Vondra
>     <tomas.vondra@enterprisedb.com
>     <mailto:tomas.vondra@enterprisedb.com>> wrote:
> 
>      > FWIW I don't understand why would they need to write parsers.
> 
>     It's quite common to write unit tests for VM recipes/playbooks wheen
>     using
>     tools like Chef etc, parsing and checking the installed/generated
>     files is part
>     of that. This would be one very real use case for writing a parser.
> 
> 
> Consider pgAdmin and the many other tools which essentially embed 
> pg_dump and pg_restore.  There’s no shortage of use cases for a variety 
> of tools to be able to understand, read, parse, generate, rewrite, and 
> probably do more, with such a pg_dump/restore config file.
> 

Sure. Which is why I'm advocating for the simplest possible format (and 
not expanding the scope of this patch beyond filtering), because that 
makes this kind of processing simpler.

>      > I think the case when the filter file needs to be modified is
>     rather rare - it certainly is not what the original use case Pavel
>     tried to address needs. (I know that customer and the filter would
>     be generated and used for a single dump.)
> 
>     I'm not convinced that basing design decisions on a single customer
>     reference
>     who only want to use the code once is helpful. 
> 
> 
> Agreed.
> 

I wasn't really basing this on a single customer - that was merely an 
example, of course. FWIW Justin Pryzby already stated having to use some 
more complex format would likely mean they would not use the feature, so 
that's another data point to consider.

FWIW I believe it's clear what my opinions on this topic are. Repeating 
that seems a bit pointless, so I'll step aside and let this thread move 
forward in whatever direction.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company