| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Lætitia Avrot <laetitia(dot)avrot(at)gmail(dot)com>, Ryan Lambert <ryan(at)rustprooflabs(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, ahsan hadi <ahsan(dot)hadi(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_dump new feature: exporting functions only. Bad or good idea ? |
| Date: | 2022-01-25 05:49:10 |
| Message-ID: | Ye+PVtkDmA574BL2@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 09, 2021 at 03:23:07PM +0100, Daniel Gustafsson wrote:
> Looking at this thread I think it makes sense to go ahead with this patch. The
> filter functionality worked on in another thread is dealing with cherry-picking
> certain objects where this is an all-or-nothing switch, so I don't think they
> are at odds with each other.
Including both procedures and functions sounds natural from here. Now
I have a different question, something that has not been discussed in
this thread at all. What about patterns? Switches like --table or
--extension are able to digest a psql-like pattern to decide which
objects to dump. Is there a reason not to have this capability for
this new switch with procedure names? I mean to handle the case
without the function arguments, even if the same name is used by
multiple functions with different arguments.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2022-01-25 05:49:38 | Re: Printing backtrace of postgres processes |
| Previous Message | tanghy.fnst@fujitsu.com | 2022-01-25 05:22:32 | RE: Support tab completion for upper character inputs in psql |