Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wfCAa-005KEG-2i for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Jul 2026 07:49:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wfCAZ-000qk0-2H for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Jul 2026 07:49:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wfCAZ-000qjq-0t for pgsql-hackers@lists.postgresql.org; Thu, 02 Jul 2026 07:49:11 +0000 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wfCAU-00000001CoF-3FlN for pgsql-hackers@lists.postgresql.org; Thu, 02 Jul 2026 07:49:08 +0000 Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-c12620ed112so187286166b.3 for ; Thu, 02 Jul 2026 00:49:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782978544; cv=none; d=google.com; s=arc-20260327; b=hb6n7XmSgxso+uTDwMYUhwI6iqlSI/ygCZllYT6PZa24PQHALrzsDTFQMEhrsuMDDd 7E0nd0yJHrGdRs1Cc9FwgqAh4LFa5xsgNK67JxkChb7l+To76RuL+RDatMMtMNpLtslu cESt41gD4/tFT3tiKfcnrAI6eLmeFqD1ZNbhLhhon6lKpF1UB8imuXkVpAmkV86O/6pp mADEKrGnXckTA3YmaP4zYY8i/yCX18b4qpw3WXqAMG3hMAYBmk3hJ206JT6h7jiMFsXa U8iGehmT4D1YYp+6i4orwR+BpM+KaQ5tgf0/wM3aecbZTjtzzFJhLTuCsYZTcLdYjbpP dwqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=snDKkSl51V7js9riyB1dAbtnFDCMkA68rDnRViT9fgY=; fh=RFOspku/Xx6MZH4j3VqXw0h+dgUg9IbINQtETGdYJ1k=; b=c9HBoen6Y3DBuSY18QmyxefNvHMUfsg8/6JbE88xszlPBrYUqiamRF49yHhqd83CY9 Kmyd59GViTgcr87zmObrQNMb//ufnETbQVaf7OF4g06YYCyLT/UBgELf2bC5Pa0pIBNj 8SqUA1EAxZlDHCW5K+mEfDm1ZFB4MCKf4SMeVmUg2qfRT2MrFgeoJCEkTkZtRoKd5Mc0 KPx2Z/N3Lidw2QOMgeK8VvjdoaQXkRJhbhErxufOficNBR5++ohLeG2YC7VyjSoD7WY2 ri5ZwvZjQRLmOaCTsJhOBV4mKMXSu3LiVTTSvDZQjn0dS45FKED2KZKso8BLGFT/wBKn 8rAQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1782978544; x=1783583344; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=snDKkSl51V7js9riyB1dAbtnFDCMkA68rDnRViT9fgY=; b=Bl31zHp3zZCXJWg9IyJ4d9S7a3VOL0oXnNfL7OHKEYagN+CZachQH+QXWCn3cDI4zx QQsAgxWk10LjmUO8A7xEjSIyaekuLBRPBKDVddxOu5BgNS7K80Ku1+75RU0/rsg+HICc Cr7eaqwId0OwrVqSTZWNMMViIvBWV7FA7+Hlat4L6h9GyY9Mwo5j4/40c8QvZrq9zC7E PjaUkcDne6JxqudLW3sM4UnxCCDhFN/hPufAPew9mbntQUtdi1GEFH1udB5acrAAZK2c +xXBa/U9HQIMlmKHXulLVjCtDlAcLy1to+Epaj1BJ8sdTG7KEiL5eXIc6HlYlHuVygHL ykVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782978544; x=1783583344; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=snDKkSl51V7js9riyB1dAbtnFDCMkA68rDnRViT9fgY=; b=r6W6YbY7N+gedaF2XPNFBlMVf4P3zxO1JDrtwcqdEAcBmgHqMp/qIEOJc0p1ArGLsb Uqlx2cEAEi6uo6U29xgCYcPmd0teJMWVBKLqjZ/SVVVI8oB87fvrc7KI9JfjbCQt5AkL 4064Y+s2zf4c2MLprhMmTtenwXcz+8CCDDiA1RRKqwWjq1mTT/8Tk/pJA+xl9R+/ZkMs 3nx5/PN6RFEbRqGRpne3UtiRqMPYgZNgHJ17KhHUVpwRCsekSMD5PLvHt9CGpCUw42fe N3oHO1jcKocshpRvIbG1H+nrS87hgYAOk70Cqhaq0+4DuNE4vvGE2lPwBqbgsjZ/gBvT GR/A== X-Forwarded-Encrypted: i=1; AHgh+RqRxpBoInSRzyoKATx41W8pQpWgvGP6F35A0itsb+qsiZhJ7cvEB8JyhYW3pCIZlOu7MhNA6qGbOLhkCDls@lists.postgresql.org X-Gm-Message-State: AOJu0YwSCZV+2wEi3WZ882xACSIa7JAys9JwX6iOyXHz60O6C7A9Q9re pUahlfesx6Jjc/48mo6fsJLUH5MEkKePJ+zpmQsq0mnsQgRJT+upZvCdYCcd4XGfFqQUgYW5VOP +AqfQmPlNk9TtV+YcXifV82tEDnAIVVeoC+e7Yy7o X-Gm-Gg: AfdE7cnisaJlQWp98Yyt7AbeWnqEi8P1SYeBttuS7n9uKbN1H4mIq/NaMEaYZMQP7Lf rHNvric4DSY4tVthjwZN2ZMpJk/pCU17oHzp67MhG+njpgMiU5aB8wkdErrwC82F5EwtX1PHXuz xAgtMqsy4BlDSFP1IVIFRGfPkIuHcUVppsoHAqNGbYSOZ8e3yAmD7HwM/wW15foNdBpzSTjXpGc 4sts0aIHr9AQjF/Uct90Jw73szbgrHc4GIKIaXdoxkp3NhEV5TqhCUpnfeHuvOHJlB1A4BPBPE= X-Received: by 2002:a17:907:84e:b0:c12:8b1c:454f with SMTP id a640c23a62f3a-c12a9d1938emr188465566b.2.1782978543718; Thu, 02 Jul 2026 00:49:03 -0700 (PDT) MIME-Version: 1.0 References: <983C7B03-D9C3-4F15-8913-7616EC5E6414@gmail.com> <20260623.162104.775158751399277188.horikyota.ntt@gmail.com> In-Reply-To: From: Akshay Joshi Date: Thu, 2 Jul 2026 13:18:51 +0530 X-Gm-Features: AVVi8CeL1Q4bsY2aIOemM4PgLioFgTAEwNc12EHAGI60YfXbvn6Npn2bFLoBg5c Message-ID: Subject: Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements To: Marcos Pegoraro Cc: Zsolt Parragi , pgsql-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000bdb20606559c0a82" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000bdb20606559c0a82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 1, 2026 at 8:41=E2=80=AFPM Marcos Pegoraro = wrote: > Em qua., 1 de jul. de 2026 =C3=A0s 11:12, Akshay Joshi < > akshay.joshi@enterprisedb.com> escreveu: > >> pretty, owner, tablespace, and schema_qualified are plain boolean >> parameters with DEFAULT values >> *Filtering parameters:* *only_kinds* / *except_kinds* as text[] >> >>> If all parameters are optional, and all parameters are boolean, perhaps > you could also make pretty, owner, tablespace, and schema_qualified as > optional parts of only_kinds and except_kinds. > > Therefore, we could call these two ways and the result would be the same. > pg_get_table_ddl('idxd'::regclass, owner =3D> false, tablespace =3D> fals= e, except_kinds > =3D> '{primary_key}'); > pg_get_table_ddl('idxd'::regclass, except_kinds =3D> '{primary_key, > tablespace,owner}'); > > Obviously this way you have to know if owner param is false or it exists > on except_kinds. > What do you think ? > *owner* is the one case where it could work, but to make it consistent with how owner behaves in pg_get_tablespace_ddl and pg_get_database_ddl, we should not add it. *tablespace* doesn't map to a kind at all. It controls the inline TABLESPACE clause within the CREATE TABLE statement body it's a sub-clause, not a separate statement. If we added tablespace as a kind, except_kinds = =3D> '{table,tablespace}' would be wrong (if you're skipping the table statement, there's no inline clause to suppress), and except_kinds =3D> '{tablespace}' would imply skipping a standalone statement that doesn't exist. *pretty* and *schema_qualified* are rendering/formatting options, not statement filters. They affect how every statement is rendered =E2=80=94 indentation, name qualification =E2=80=94 not which statements are emitted.= Putting them in except_kinds conflates two orthogonal axes: filtering (what to emit) and formatting (how to emit it). The current design intentionally keeps these separate: only_kinds/except_kinds for statement-level filtering, booleans for rendering and inline-clause control. Merging them would make except_kinds overloaded and harder to document clearly. > > regards > Marcos > --000000000000bdb20606559c0a82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 1, = 2026 at 8:41=E2=80=AFPM Marcos Pegoraro <marcos@f10.com.br> wrote:
<= div dir=3D"ltr">
Em qua., 1 de jul. de= 2026 =C3=A0s 11:12, Akshay Joshi <akshay.joshi@enterprisedb.com> escreve= u:
pretty, owner, tablespace, and=C2=A0schema_qualified are plain boolean parame= ters with DEFAULT values
Filtering parameters: only_kinds / except_kinds a= s text[]=C2=A0
If all parameters are optional, and all parameters are boolean, perhaps= you could also make pretty, owner, tablespace, and schema_qualified as opt= ional parts of only_kinds and except_kinds.

Therefore, we could call thes= e two ways and the result would be the same.
pg_ge= t_table_ddl('idxd'::regclass, owner = =3D> false, tablespace =3D> false,=C2=A0except_kinds =3D> '{primary_key}');
pg_get_table_ddl('idxd'::regclass, except_kinds =3D> '{prim= ary_key,tablespace,owner}');
<= div style=3D"font-family:verdana,sans-serif;color:rgb(102,102,102)">
Obviously this way you have to know if owner=C2=A0param = is false or it exists on=C2=A0except_kinds.=C2=A0
What do you think ?

owner is the one case where it could wo= rk, but to make it consistent with how owner behaves in pg_get_tablespace_d= dl and pg_get_database_ddl, we should not add it.

tablespace doesn't= map to a kind at all. It controls the inline TABLESPACE clause within the = CREATE TABLE statement body it's a sub-clause, not a separate statement= . If we added tablespace as a kind, except_kinds =3D> '{table,tables= pace}' would be wrong (if you're skipping the table statement, ther= e's no inline clause to suppress), and except_kinds =3D> '{table= space}' would imply skipping a standalone statement that doesn't ex= ist.

pretty and schema_qual= ified are rendering/formatting options, not statement filters. They aff= ect how every statement is rendered =E2=80=94 indentation, name qualificati= on =E2=80=94 not which statements are emitted. Putting them in except_kinds= conflates two orthogonal axes: filtering (what to emit) and formatting (ho= w to emit it).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
T= he current design intentionally keeps these separate: only_kinds/except_kin= ds for statement-level filtering, booleans for rendering and inline-clause = control. Merging them would make except_kinds overloaded and harder to docu= ment clearly.
regar= ds
Marcos
--000000000000bdb20606559c0a82--