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

Hi

st 25. 11. 2020 v 19:25 odesílatel Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
napsal:

> On Thu, 19 Nov 2020 at 19:57, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >
> > minor update - fixed handling of processing names with double quotes
> inside
> >
>
> I see this is marked RFC, but reading the thread it doesn't feel like
> we have reached consensus on the design for this feature.
>
> I agree that being able to configure pg_dump via a config file would
> be very useful, but the syntax proposed here feels much more like a
> hacked-up syntax designed to meet this one use case, rather than a
> good general-purpose design that can be easily extended.
>

Nobody sent a real use case for introducing the config file. There was a
discussion about formats, and you introduce other dimensions and
variability.

But I don't understand why? What is a use case? What is a benefit against
command line, or libpq variables? And why should config files be better as
a solution for limited length of command line, when I need to dump
thousands of tables exactly specified?

Regards

Pavel

> IMO, a pg_dump config file should be able to specify all options
> currently supported through the command line, and vice versa (subject
> to command line length limits), with a single common code path for
> handling options. That way, any new options we add will work on the
> command line and in config files. Likewise, the user should only need
> to learn one set of options, and have the choice of specifying them on
> the command line or in a config file (or a mix of both).
>
> I can imagine eventually supporting multiple different file formats,
> each just being a different representation of the same data, so
> perhaps this could work with 2 new options:
>
> --option-file-format=plain|yaml|json|...
> --option-file=filename
>

> with "plain" being the default initial implementation, which might be
> something like our current postgresql.conf file format.
>
> Also, I think we should allow multiple "--option-file" arguments
> (e.g., to list different object types in different files), and for a
> config file to contain its own "--option-file" arguments, to allow
> config files to include other config files.
>
> The current design feels far too limited to me, and requires new code
> and new syntax to be added each time we extend it, so I'm -1 on this
> patch as it stands.

This new syntax tries to be consistent and simple. It really doesn't try to
implement an alternative configuration file for pg_dump. The code is simple
and can be easily extended.

What are the benefits of supporting multiple formats?

> Regards,
> Dean
>