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

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Surafel Temesgen <surafel3000(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Re: proposal: possibility to read dumped table's name from file
Date: 2021-07-10 15:47:12
Message-ID: cb545d78-2dae-8d27-f062-822a07ca56cf@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I started looking at the patch allowing to export just functions [1],
and I got pointed to this patch as an alternative approach (to adding a
separate filtering option for every possible object type).

I'm familiar with the customer that inspired Pavel to start working on
this, so I understand the use case he's trying to address - a flexible
way to filter (include/exclude) large number of objects.

IMHO it's a mistake to try to broaden the scope of the patch and require
implementing some universal pg_dump config file, particularly if it
requires "complex" structure or formats like JSON, TOML or whatever.
Maybe that's worth doing, but in my mind it's orthogonal to what this
patch aims (or aimed) to do - filtering objects using rules in a file,
not on the command line.

I believe it's much closer to .gitignore or rsync --filter than to a
full config file. Even if we end up implementing the pg_dump config
file, it'd be nice to keep the filter rules in a separate file and just
reference that file from the config file.

That also means I find it pointless to use an "advanced" format like
JSON or TOML - I think the format should be as simple as possible. Yes,
it has to support all valid identifiers, comments and so on. But I don't
quite see a point in using JSON or similar "full" format. If a simple
format is good enough for rsync or gitignore, why should we insist on
using something more complex?

OTOH I don't quite like the current approach of simply reading options
from a file, because that requires adding new command-line options for
each type of object we want to support. Which seems to contradict the
idea of "general filter" method as mentioned in [1].

So if it was up to me, I'd go back to the original format or something
close it. So something like this:

[+-] OBJECT_TYPE_PATTERN OBJECT_NAME_PATTERN

regards

[1] https://commitfest.postgresql.org/33/3051/

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2021-07-10 16:02:50 Re: Enhanced error message to include hint messages for redundant options error
Previous Message Tom Lane 2021-07-10 15:01:12 Re: pgsql: Fix numeric_mul() overflow due to too many digits after decimal