Re: [PATCH] Add pg_get_type_ddl() to retrieve the CREATE TYPE statement

From: Quan Zongliang <quanzongliang(at)yeah(dot)net>
To: Philip Alger <paalger0(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Add pg_get_type_ddl() to retrieve the CREATE TYPE statement
Date: 2025-10-31 07:27:15
Message-ID: 1638bfee-fddb-48ac-b62e-3e2e67addb5b@yeah.net
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/31/25 9:34 AM, Philip Alger wrote:
> Hi Quan,
>
> This is part of a larger project as noted here:
>
Understood. This is an amazing job.

> > I am submitting a patch as part of the Retail DDL functions project
> > described here [1].
>
> > 1. https://www.postgresql.org/message-id/945db7c5-be75-45bf-b55b-
> <https://www.postgresql.org/message-id/945db7c5-be75-45bf-b55b->
> > cb1e56f2e3e9%40dunslane.net <http://40dunslane.net> <https://
> www.postgresql.org/message- <https://www.postgresql.org/message->
> > id/945db7c5-be75-45bf-b55b-cb1e56f2e3e9%40dunslane.net
> <http://40dunslane.net>>
>
>
> The idea here is to look up the created TYPE by its name and not the
> OID. The function that is close is pg_get_viewdef(text) [1], but that's
> deprecated.
>  Also, see threads for:
>
> A. pg_get_trigger_ddl [2]
> B. pg_get_tablespace_ddl [3]
> C. pg_get_role_ddl [4]
> D. pg_get_policy_ddl [5]
> E. pg_get_domain_ddl [6]
>
> 1.https://www.postgresql.org/docs/18/functions-info.html <https://
> www.postgresql.org/docs/18/functions-info.html>
> 2. https://www.postgresql.org/message-id/flat/
> CAPXBC8K5awmtMoq66DGHe%2BnD7hUf6HPRVHLeGNBRpCDpzusOXQ%40mail.gmail.com
> <https://www.postgresql.org/message-id/flat/
> CAPXBC8K5awmtMoq66DGHe%2BnD7hUf6HPRVHLeGNBRpCDpzusOXQ%40mail.gmail.com>
> 3. https://www.postgresql.org/message-id/flat/CAKWEB6rmnmGKUA87Zmq-
> s%3Db3Scsnj02C0kObQjnbL2ajfPWGEw%40mail.gmail.com <https://
> www.postgresql.org/message-id/flat/CAKWEB6rmnmGKUA87Zmq-
> s%3Db3Scsnj02C0kObQjnbL2ajfPWGEw%40mail.gmail.com>
> 4. https://www.postgresql.org/message-id/flat/4c5f895e-3281-48f8-
> b943-9228b7da6471%40gmail.com <https://www.postgresql.org/message-id/
> flat/4c5f895e-3281-48f8-b943-9228b7da6471%40gmail.com>
> 5. https://www.postgresql.org/message-id/flat/
> CANxoLDdJsRJqnjMXV3yjsk07Z5iRWxG-c2hZJC7bAKqf8ZXj_A%40mail.gmail.com
> <https://www.postgresql.org/message-id/flat/
> CANxoLDdJsRJqnjMXV3yjsk07Z5iRWxG-c2hZJC7bAKqf8ZXj_A%40mail.gmail.com>
> 6. https://www.postgresql.org/message-id/flat/
> CAPgqM1URzR017U5gEK6S5dYz8VdYMaJf82G9sZFq5xbpHR1J_g%40mail.gmail.com#b1acf1f04ba8b36239fccdfae0110d3d <https://www.postgresql.org/message-id/flat/CAPgqM1URzR017U5gEK6S5dYz8VdYMaJf82G9sZFq5xbpHR1J_g%40mail.gmail.com#b1acf1f04ba8b36239fccdfae0110d3d>
>
> --
> Best,
> Phil Alger

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-10-31 07:41:46 Re: Consistently use the XLogRecPtrIsInvalid() macro
Previous Message Lukas Fittl 2025-10-31 07:18:04 Re: Stack-based tracking of per-node WAL/buffer usage