| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Laetitia Avrot <laetitia(dot)avrot(at)gmail(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Vik Fearing <vik(at)postgresfriends(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_dump new feature: exporting functions only. Bad or good idea ? |
| Date: | 2022-03-25 18:37:11 |
| Message-ID: | 3452905.1648233431@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Fri, Mar 25, 2022 at 10:57 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> pg_dump never dumps system objects, so I don't see a need for
>> a switch to tell it not to.
> I considered pg_class to be a system object, which was dumped under -t '*'
Oh! You're right, the --table switches will include system objects.
That seems like a bug TBH. Even if it's intentional, it's surely
not behavior we want for functions. You can somewhat easily
exclude system catalogs from matching --table since they all have
names starting with "pg_", but it'd be way more painful for functions
because (a) there are thousands and (b) they're not very predictably
named.
I'd vote for changing the behavior of --table rather than trying to
be bug-compatible with this decision.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2022-03-25 18:40:01 | Re: pg_dump new feature: exporting functions only. Bad or good idea ? |
| Previous Message | Robert Haas | 2022-03-25 18:34:30 | Re: Add non-blocking version of PQcancel |