Re: Re: pg_dump new feature: exporting functions only. Bad or good idea ? - Mailing list pgsql-hackers

From Laetitia Avrot
Subject Re: Re: pg_dump new feature: exporting functions only. Bad or good idea ?
Date
Msg-id CAB_COdic1FJ1nQPcffW5PzqxB9xcUvMzpsdvur9ogduSquabMg@mail.gmail.com
Whole thread Raw
In response to Re: Re: pg_dump new feature: exporting functions only. Bad or good idea ?  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Re: pg_dump new feature: exporting functions only. Bad or good idea ?  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
Hello David,

thank you for your interest in that patch.

Le ven. 25 mars 2022 à 01:17, David G. Johnston <david.g.johnston@gmail.com> a écrit :
On Thu, Mar 24, 2022 at 4:42 PM Chapman Flack <chap@anastigmatix.net> wrote:
On 03/27/21 08:57, Andrew Dunstan wrote:
> We can bikeshed the name of the flag at some stage. --procedures-only
> might also make sense

Any takers for --routines-only ?

"Routine" is the genuine, ISO SQL umbrella term for a function or
procedure, and we have used it that way in our docs and glossary.


Regardless of the prefix name choice neither blobs, tables, nor schemas use the "-only" suffix so I don't see that this should.  I have no issue if we add three options for this: --routine/--procedure/--function (these are singular because --table and --schema are singular)

Actually, I thought of it after the --schema-only flag (which is kind of confusing, because it won't export only schema creation DDL). I agree to keep the flag name singular if we're using a pattern to cherry-pick the objects we want. My problem is how do you think we could get all the stored procedures/functions at once? --function=* ? It seems to me that exporting everything at once is the main use case (I'd be happy to be proven wrong), and it does not feel intuitive to use --function=*.

How would you see to create 3 flags: --functions-only /  --function=<pattern> / --exclude-function=<pattern> ?
And then we could create the same series of 3 flags for other objects. Would that be too verbose?

--blobs and --no-blobs are special so let us just build off of the API already implemented for --table/--exclude-table

No short option is required, and honestly I don't think it is worthwhile to take up short options for this, acknowledging that we are leaving -t/-T (and -n/-N) in place for legacy support.

I agree
 

--blobs reacts to these additional object types in the same manner that it reacts to --table.  As soon as any of these object type inclusion options is specified nothing except the options that are specified will be output.  Both data and schema, though, for most object types, data is not relevant.  If schema is not output then options that control schema content objects only are ignored.

The --exclude-* options behave in the same way as defined for -t/-T, specifically the note in -T about when both are present.

As with tables, the affirmative version of these overrides any --schema (-n/-N) specification provided.  But the --exclude-* versions of these do omit the named objects from the dump should they have been selected by --schema.

That's fine with me.

Have a nice day,

Lætitia
 

David J.

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pgsql: Add 'basebackup_to_shell' contrib module.
Next
From: Tomas Vondra
Date:
Subject: Re: logical decoding and replication of sequences