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.94.2) (envelope-from ) id 1te7Pd-00BzqE-Fp for pgsql-hackers@arkaria.postgresql.org; Sat, 01 Feb 2025 06:55:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1te7Pb-004IQ0-B0 for pgsql-hackers@arkaria.postgresql.org; Sat, 01 Feb 2025 06:55:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1te7Pb-004IPs-0S for pgsql-hackers@lists.postgresql.org; Sat, 01 Feb 2025 06:55:27 +0000 Received: from mail-pj1-x1041.google.com ([2607:f8b0:4864:20::1041]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1te7PY-002f7p-0J for pgsql-hackers@lists.postgresql.org; Sat, 01 Feb 2025 06:55:26 +0000 Received: by mail-pj1-x1041.google.com with SMTP id 98e67ed59e1d1-2ef748105deso3584116a91.1 for ; Fri, 31 Jan 2025 22:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738392922; x=1738997722; darn=lists.postgresql.org; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=ldcpf+duhj0o4bxghu/6ncVYvaZffWuynZ6ZOAo37gg=; b=LOZwFtv0qG+nU2yzn6t1W8hlKKHat3grJGJUrQNFtO5VG8evh84FnfCQwtCtmc+2mY xvcXRH5G6nsySwNe1fYjnLov4shtbHZYtxPXbt2W6Jd1kzbCiROwJ2AvimCx+aPQDwLH 3SauruWASNaQpMc3Yix4/JawVLV78U/c3GeowLZI4KRH70BenisLdRGCysTBrU1IPhv2 5/tZcgzvXnxyUU/ADo5cG0hZ6KehZ6wwfZi7qPy6w69uymnp/iaZ3QrdQpgidsfvgqMF PXIcTPR8zAKV3dk9tJSfBc79AqsxECc2BZe4ShHt69yWyZw23oc5+KvvisDV6YTo2GXj 5Adg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738392922; x=1738997722; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ldcpf+duhj0o4bxghu/6ncVYvaZffWuynZ6ZOAo37gg=; b=YUBKSNaa4sDNgHfsDBt9LEtdAIinpTNIxpZw4ZwO0j+MqX1bMhHqqg7RGAfHWuPHrk pVukyYXGfl3AD+cXUQU2SjbYi5Zm888CsClo5sgb8SzRHFHA8T/ic9B4+XGyx/nW90Ur WY3cW7roktSqR2cEfr7RMotxXJJSA1qsbyT6IaQ5YJlkWDINu4/aatY20RsAFgkUjA2q JOidM2ccPOQmLkIulGUVZ/342vhQANsEW/yuXVg2IDiHp9K67nPu/WhtLkei51CjmklJ sjcQPuaQpTY9P5sMCjbfHxyZ7GnW5vq16wLrlYDucjFo3b5xi5hXink274b12T+fnt6x Y1/Q== X-Gm-Message-State: AOJu0YwfNwp4cQ0ZWIyeQRgwaCN8RYwpl+Ck82ffgaRU2pZtxRpPL16v zAu7Qz9MbmUJm84PCQAtNqYc/Tb3ruuYZ63Bj6gf77ZlXJlUMQa8tSNq/5hmlRfWyA== X-Gm-Gg: ASbGncu+3lQRpcFlylMo1PXVvnagCeYspjyNtL8z+Ww1+asD00HCVwXnZrd39hQZhrq mBNwYLHlIv6S7+tsJyJWEdjkeSF1m1nKP3gAuWCZseyk2NFQW0BBKrYYYt+nQZ4gba6GLhRaCz0 FB5hZcMQI7VG/mkjVeBcmPrB7nFAj7QQYcmVZNgx7ZmeYAgaRv6VzMpvyJx5kRy8jNi22W9Hpgu 6vaJ2NP0BoK0Mw6ExNJ5zx/0B1wdooiQfOUHvzMwFgQZqAbmQ9hjy1C7u5zVoXjihxIFz0r049/ cl2ARXvOfNyVVTHIxw== X-Google-Smtp-Source: AGHT+IGSuxvh5IAm45+Tk3j8ZFwV5liPxOhJ5I0qR7qLW+kj2YnJZ2UlWPXsRDvg6PmVP5FSWkW8eA== X-Received: by 2002:a05:6a00:4652:b0:728:e906:e466 with SMTP id d2e1a72fcca58-72fd0c7c6b2mr19596400b3a.21.1738392922010; Fri, 31 Jan 2025 22:55:22 -0800 (PST) Received: from [127.0.0.1] ([2406:da18:81d:bd00:7e58:3691:e01b:3cb]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-acebe856835sm3491098a12.33.2025.01.31.22.55.20 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jan 2025 22:55:21 -0800 (PST) Date: Sat, 1 Feb 2025 14:55:12 +0800 From: Zhang Mingli To: PostgreSQL Hackers Message-ID: <42d3f855-2275-4361-a42a-826172ca2dc4@Spark> In-Reply-To: <8eac1bb4-bfbf-4b32-b439-adcbdcd9ed98@Spark> References: <8eac1bb4-bfbf-4b32-b439-adcbdcd9ed98@Spark> Subject: Proposal to CREATE FOREIGN TABLE LIKE X-Readdle-Message-ID: 42d3f855-2275-4361-a42a-826172ca2dc4@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="679dc556_7117cfb_10188" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --679dc556_7117cfb_10188 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, all I wanted to bring up an idea that could really help out. Our DBA team uses foreign tables for ETL processes in Greenplum and Cloud= berry, and we often need to create foreign tables that match the column definiti= ons of local tables. When dealing with wide tables and lots of those foreign tables, it can ge= t pretty tedious and mistakes happen easily. We end up having to troubleshoot errors when querying, which is a hassle.= Sure, we could use=C2=A0pg=5Fdump=C2=A0to get the table DDL and modify th= e name, but that just adds more busywork. CREATE =46OREIGN TABLE LIKE=C2=A0command could save a lot of time and red= uce errors in the long run. It would work similarly to=C2=A0CREATE TABLE LIKE, copying the column def= initions and constraints from the source table. And since Postgres doesn=E2=80=99t enforce constraints on foreign tables,= it=E2=80=99s up to the user to make sure the constraints match the actua= l data. https://www.postgresql.org/docs/current/sql-createforeigntable.html This means that enabling=C2=A0CREATE =46OREIGN TABLE LIKE=C2=A0shouldn=E2= =80=99t introduce more issues with constraints I haven=E2=80=99t rush with the codes yet, but it seems like it could be = straightforward to implement by tweaking the existing limitations: =60=60=60 static void transformTableLikeClause(CreateStmtContext *cxt, TableLikeClause *table=5F= like=5Fclause) =7B ... if (cxt->isforeign) ereport(ERROR, (errcode(ERRCODE=5F=46EATURE=5FNOT=5FSUPPORTED), errmsg(=22LIKE is not supported for creating foreign tables=22))); =7D =60=60=60 with some test cases and Documents changes. Zhang Mingli www.hashdata.xyz --679dc556_7117cfb_10188 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi, all


I wanted to bring up an idea that could really help out.
Our DBA team uses foreign tables for ETL processes in Greenplum and Cloud= berry,
and we often need to create foreign tables that match the column definiti= ons of local tables.

When dealing with wide tables and lots of those foreign tables, it can ge= t pretty tedious and mistakes happen easily.&=23160;
We end up having to troubleshoot errors when querying, which is a hassle.= &=23160;
Sure, we could use&=23160;pg=5Fdump&=23160;to get the table = DDL and modify the name, but that just adds more busywork.
CREATE =46OREIGN TABLE LIKE&=23160;command could save a lot = of time and reduce errors in the long run.
It would work similarly to&=23160;CREATE TABLE LIKE, copying= the column definitions and constraints from the source table.

And since Postgres doesn=E2=80=99t enforce constraints on foreign tables,= it=E2=80=99s up to the user to make sure the constraints match the actua= l data.&=23160;
https://www.postgresql.org/docs/curren= t/sql-createforeigntable.html

This means that enabling&=23160;CREATE =46OREIGN TABLE LIKE&= =23160;shouldn=E2=80=99t introduce more issues with constraints

I haven=E2=80=99t rush with the codes yet, but it seems like it could be = straightforward to implement by tweaking the existing limitations:&=23160= ;

=60=60=60
static void
transformTableLikeClause(CreateStmtContext *cxt, TableLikeClause *table=5F= like=5Fclause)
=7B
...
if (cxt->isforeign)
ereport(ERROR,
(errcode(ERRCODE=5F=46EATURE=5FNO= T=5FSUPPORTED),
errmsg(=22LIKE is not supported = for creating foreign tables=22)));
=7D
=60=60=60

with some test cases and Documents changes.


Zhang Mingli
www.hashdata.xyz
--679dc556_7117cfb_10188--