> On Sat, Jul 10, 2021 at 5:06 AM Tomas Vondra <
tomas.vondra@enterprisedb.com> wrote:
> On 7/10/21 1:43 AM, Tom Lane wrote:
>> Tomas Vondra <
tomas.vondra@enterprisedb.com> writes:
>>> The main question I have is whether this should include procedures.
>>
>> I feel a bit uncomfortable about sticking this sort of limited-purpose
>> selectivity mechanism into pg_dump. I'd rather see a general filter
>> method that can select object(s) of any type. Pavel was doing some
>> work towards that awhile ago, though I think he got frustrated about
>> the lack of consensus on details. Which is a problem, but I don't
>> think the solution is to accrue more and more independently-designed-
>> and-implemented features that each solve some subset of the big problem.
>>
>
> I'm not against introducing such general filter mechanism, but why
> should it block this patch? I'd understand it the patch was adding a lot
> of code, but that's not the case - it's tiny. And we already have
> multiple filter options (to pick tables, schemas, extensions, ...).
> And if there's no consensus on details of Pavel's patch after multiple
> commitfests, how likely is it it'll start moving forward?
It seems to me that pg_dump already has plenty of limited-purpose options for selectivity, adding this patch seems to fit in with the norm. I'm in favor of this patch because it works in the same way the community is already used to and meets the need. The other patch referenced upstream appears to be intended to solve a specific problem encountered with very long commands. It is also introducing a new way of working with pg_dump via a config file, and honestly I've never wanted that type of feature. Not saying that wouldn't be useful, but that has not been a pain point for me and seems overly complex. For the use cases I imagine this patch will help with, being required to go through a config file seems excessive vs pg_dump --functions-only.
> On Fri, Jul 9, 2021 at 4:43 PM Tomas Vondra <
tomas.vondra@enterprisedb.com> wrote:
>
> The main question I have is whether this should include procedures. I'd
> probably argue procedures should be considered different from functions
> (i.e. requiring a separate --procedures-only option), because it pretty
> much is meant to be a separate object type. We don't allow calling DROP
> FUNCTION on a procedure, etc. It'd be silly to introduce an unnecessary
> ambiguity in pg_dump and have to deal with it sometime later.
+1
Ryan Lambert
RustProof Labs
