Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1peH9M-0003Rn-Ds for pgsql-admin@arkaria.postgresql.org; Mon, 20 Mar 2023 15:10:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1peH9K-0003Rm-Oy for pgsql-admin@arkaria.postgresql.org; Mon, 20 Mar 2023 15:10:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1peH9K-0003RZ-EA for pgsql-admin@lists.postgresql.org; Mon, 20 Mar 2023 15:10:14 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1peH9H-0000jc-HT for pgsql-admin@postgresql.org; Mon, 20 Mar 2023 15:10:14 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 32KFA8bG938035; Mon, 20 Mar 2023 11:10:08 -0400 From: Tom Lane To: richard coleman cc: pgsql-admin Subject: Re: PostgreSQL equivalents to dbms_metadata.get_ddl & dbms_metadata.get_dependent_ddl In-reply-to: References: Comments: In-reply-to richard coleman message dated "Mon, 20 Mar 2023 10:48:45 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <938033.1679325008.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Mar 2023 11:10:08 -0400 Message-ID: <938034.1679325008@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk richard coleman writes: > Look below for the difference in the two functions, how they are used, t= he > 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=3Dpostgresql.git;a=3Dcommitdiff;h= =3Da563c24c9574b74f4883c004c89275bba03c3c26