From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | richard coleman <rcoleman(dot)ascentgl(at)gmail(dot)com> |
Cc: | pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL equivalents to dbms_metadata.get_ddl & dbms_metadata.get_dependent_ddl |
Date: | 2023-03-20 15:10:08 |
Message-ID: | 938034.1679325008@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
richard coleman <rcoleman(dot)ascentgl(at)gmail(dot)com> writes:
> Look below for the difference in the two functions, how they are used, the
> amount of knowledge you need to posses in order to run them and the
> difference in the output.
I'm not finding this terribly convincing, because I don't exactly see
what is the use-case for having that DDL in isolation. Or in other
words, what is your use-case that you find pg_dump so unsatisfactory
for? It knows all this stuff, and it also knows things like which
other objects a given object depends on and how to cope with circular
dependencies. Most of the reasons that I can think of for wanting
the pg_get_*def functions that we don't already have seem to reduce
to building partially-baked versions of pg_dump.
If your concern is that you can't get pg_dump to slice up the schema
in exactly the way you want, adding some more options to it might be
an easier sell than implementing/maintaining a bunch of duplicate
functionality. We just got done adding [1], for example.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | richard coleman | 2023-03-20 15:48:37 | Re: PostgreSQL equivalents to dbms_metadata.get_ddl & dbms_metadata.get_dependent_ddl |
Previous Message | MichaelDBA | 2023-03-20 14:49:12 | Re: PostgreSQL equivalents to dbms_metadata.get_ddl & dbms_metadata.get_dependent_ddl |