MIME-Version: 1.0
References: 
 <CANxoLDd0KT+5fHOyTi0Fu5Jwme0+a5S2aAVj=iCVsqkpvF_2TA@mail.gmail.com>
 <CAN4CZFPxokhJ2vTiTu9Bhj+v7T+5jZd4pjT7QXdjoZ4Vqv5KhQ@mail.gmail.com>
 <CANxoLDdVEjCCKch1O-5J6ghw89b2fkWC1ADPYTUwxu8WB-hQbw@mail.gmail.com>
 <20260702.111715.277646207293239004.horikyota.ntt@gmail.com>
In-Reply-To: <20260702.111715.277646207293239004.horikyota.ntt@gmail.com>
From: Akshay Joshi <akshay.joshi@enterprisedb.com>
Date: Thu, 2 Jul 2026 14:18:06 +0530
Message-ID: 
 <CANxoLDceK1w3DVbCPyricQuVKjx1qeKoWUKqyx5uoMQ8=6yguQ@mail.gmail.com>
Subject: Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE
 statements
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: zsolt.parragi@percona.com, pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000963d7f06559cde87"
Archived-At: 
 <https://www.postgresql.org/message-id/CANxoLDceK1w3DVbCPyricQuVKjx1qeKoWUKqyx5uoMQ8%3D6yguQ%40mail.gmail.com>
Precedence: bulk

--000000000000963d7f06559cde87
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 2, 2026 at 7:47=E2=80=AFAM Kyotaro Horiguchi <horikyota.ntt@gma=
il.com>
wrote:

> Hello,
>
> Looking at this, one thing that concerns me is the large amount of
> overlap with dumpTableSchema() in pg_dump.
>
> I wonder if it would make sense to separate the SQL generation logic
> into frontend/backend-shared code so that it could also be used by
> pg_dump. The catalog lookup would naturally remain separate, but
> sharing the DDL generation itself would significantly reduce the
> duplication.
>

Thanks for the suggestion. The overlap is real, but sharing the SQL
generation logic at the C level runs into a few structural mismatches:
dumpTableSchema drives column rendering off pre-populated TableInfo arrays
that pg_dump bulk-loaded at startup, while the backend function uses live
syscache lookups - a shared builder would need an adapter layer roughly as
large as the code it replaces. The pattern PostgreSQL already uses for this
kind of sharing is to call backend pg_get_*def functions via SQL from
pg_dump =E2=80=94 it already does this 20 times for indexes, constraints, t=
riggers,
rules, and statistics. The natural long-term path would be for pg_dump to
call pg_get_table_ddl() the same way and retire dumpTableSchema, but that
is a substantial refactor in its own right and feels out of scope here.

By the way, a couple of comments use a Unicode RIGHTWARDS ARROW
> (U+2192). Please use an ASCII equivalent instead.
>

   Will fix it in the next v15 patch.

>
> Regards,
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
>

--000000000000963d7f06559cde87
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 2, =
2026 at 7:47=E2=80=AFAM Kyotaro Horiguchi &lt;<a href=3D"mailto:horikyota.n=
tt@gmail.com">horikyota.ntt@gmail.com</a>&gt; wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
Looking at this, one thing that concerns me is the large amount of<br>
overlap with dumpTableSchema() in pg_dump.<br>
<br>
I wonder if it would make sense to separate the SQL generation logic<br>
into frontend/backend-shared code so that it could also be used by<br>
pg_dump. The catalog lookup would naturally remain separate, but<br>
sharing the DDL generation itself would significantly reduce the<br>
duplication.<br></blockquote><div><span style=3D"background-color:transpare=
nt"><br></span></div><div><span style=3D"background-color:transparent">Than=
ks for the suggestion. The overlap is real, but sharing the SQL generation =
logic at the C level runs into a few structural mismatches: dumpTableSchema=
 drives column rendering off pre-populated=C2=A0</span><span style=3D"backg=
round-color:transparent">TableInfo arrays that pg_dump bulk-loaded at start=
up, while the backend function uses live syscache lookups - a shared builde=
r would need an adapter layer roughly as large as the code it replaces.=C2=
=A0</span><span style=3D"background-color:transparent">The pattern PostgreS=
QL already uses for this kind of sharing is to call backend pg_get_*def fun=
ctions via SQL from pg_dump =E2=80=94 it already does this 20 times for ind=
exes, constraints, triggers, rules, and=C2=A0</span><span style=3D"backgrou=
nd-color:transparent">statistics. The natural long-term path would be for p=
g_dump to call pg_get_table_ddl() the same way and retire dumpTableSchema, =
but that is a substantial refactor in its own right and feels out of scope=
=C2=A0</span><span style=3D"background-color:transparent">here.</span></div=
><div><span style=3D"background-color:transparent"><br></span></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">
By the way, a couple of comments use a Unicode RIGHTWARDS ARROW<br>
(U+2192). Please use an ASCII equivalent instead.<br></blockquote><div>=C2=
=A0 =C2=A0<br>=C2=A0 =C2=A0Will fix it in the next v15 patch.=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
<br>
-- <br>
Kyotaro Horiguchi<br>
NTT Open Source Software Center<br>
</blockquote></div></div>

--000000000000963d7f06559cde87--