Re: proposal: possibility to read dumped table's name from file

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Tomas Vondra <[email protected]>
To: Stephen Frost <[email protected]>
To: Daniel Gustafsson <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Dean Rasheed <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: Pavel Stehule <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Surafel Temesgen <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: vignesh C <[email protected]>
Subject: Re: proposal: possibility to read dumped table's name from file
Date: Tue, 13 Jul 2021 23:57:10 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAOuzzgo=jCedUd9imehf+DtWPaHXG0K4JVDswJ35Yt=MZTkweQ@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAOuzzgo=jCedUd9imehf+DtWPaHXG0K4JVDswJ35Yt=MZTkweQ@mail.gmail.com>

On 7/13/21 10:55 PM, Stephen Frost wrote:
> Greetings,
> 
> On Tue, Jul 13, 2021 at 16:44 Daniel Gustafsson <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>      > On 13 Jul 2021, at 18:14, Tomas Vondra
>     <[email protected]
>     <mailto:[email protected]>> 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

view thread (181+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: proposal: possibility to read dumped table's name from file
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox