Re: pg_get__*_ddl consolidation

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Mahendra Singh Thalor <mahi6run(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_get__*_ddl consolidation
Date: 2026-03-19 21:30:06
Message-ID: 93b0b82c-754d-4cc3-bec8-b0eb90410c35@dunslane.net
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2026-03-19 Th 4:28 PM, Mahendra Singh Thalor wrote:
> On Fri, 20 Mar 2026 at 01:44, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>
>> You could construct these functions using plpgsql. The information isn't hidden from non-superusers. So what exactly would making these functions superuser-only achieve? Now it's true that the user might not be able to execute the DDL. But that's not the point.
> Thanks Andrew for the clarification.
>
> Sorry, my question might be stupid. Can we use these functions
> directly into our dump utilities so that common code can be removed
> and if there is any syntax change for a particular object, then no
> need to change into different-2 places, rather we just need to change
> it into ddlutils.c file only.

Well, we have tried to make the output like pg_dump. We might later
provide options for more compact output. But it remains to be seen if it
can be used in the pg_dump utilities. After all, it is going to produce
output suitable for the source version, since there is no knowledge in
the server of future versions. But pg_dump emits SQL suitable for the
target version.

My original motivation was quite different. It was to give the user a
piece of SQL that they could modify as they saw fit, rather than making
them start with a blank canvas.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2026-03-19 21:32:21 Re: pg_get__*_ddl consolidation
Previous Message Tomas Vondra 2026-03-19 20:57:32 Re: EXPLAIN: showing ReadStream / prefetch stats