Re: PostgreSQL equivalents to dbms_metadata.get_ddl & dbms_metadata.get_dependent_ddl - Mailing list pgsql-admin

From Tom Lane
Subject Re: PostgreSQL equivalents to dbms_metadata.get_ddl & dbms_metadata.get_dependent_ddl
Date
Msg-id 938034.1679325008@sss.pgh.pa.us
Whole thread Raw
In response to Re: PostgreSQL equivalents to dbms_metadata.get_ddl & dbms_metadata.get_dependent_ddl  (richard coleman <rcoleman.ascentgl@gmail.com>)
Responses Re: PostgreSQL equivalents to dbms_metadata.get_ddl & dbms_metadata.get_dependent_ddl  (richard coleman <rcoleman.ascentgl@gmail.com>)
List pgsql-admin
richard coleman <rcoleman.ascentgl@gmail.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

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a563c24c9574b74f4883c004c89275bba03c3c26



pgsql-admin by date:

Previous
From: MichaelDBA
Date:
Subject: Re: PostgreSQL equivalents to dbms_metadata.get_ddl & dbms_metadata.get_dependent_ddl
Next
From: richard coleman
Date:
Subject: Re: PostgreSQL equivalents to dbms_metadata.get_ddl & dbms_metadata.get_dependent_ddl