Feedback-ID: ia2694551:Fastmail
Date: Thu, 6 Feb 2025 11:31:43 +0100
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@alvh.no-ip.org>
To: Zhang Mingli <zmlpostgres@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Proposal to CREATE FOREIGN TABLE LIKE
Message-ID: <202502061031.wlj7ysbk7rfi@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <202502061029.s5sdtrnpfm7u@alvherre.pgsql>
Archived-At: <https://www.postgresql.org/message-id/202502061031.wlj7ysbk7rfi%40alvherre.pgsql>
Precedence: bulk

On 2025-Feb-06, Álvaro Herrera wrote:

> On 2025-Feb-06, Zhang Mingli wrote:
> 
> > Added support for CREATE FOREIGN TABLE LIKE to enable the creation of
> > foreign tables based on the column definitions, constraints of
> > existing source tables.
> > This feature mirrors the behavior of CREATE TABLE LIKE, but ignores
> > inapplicable options such as INCLUDING INDEXES and INCLUDING
> > COMPRESSION for foreign tables.
> 
> I think it'd be better to throw errors if they are given -- but
> INCLUDING ALL should be made to work in a different way than today so
> that it doesn't raise errors uselessly.  Right now it works by setting
> all the bits in the value, um.

Ah, but our fine manual already says

  The LIKE clause can also be used to copy column definitions from views,
  foreign tables, or composite types. Inapplicable options (e.g.,
  INCLUDING INDEXES from a view) are ignored.

so what you implemented seems to be okay from that POV.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Investigación es lo que hago cuando no sé lo que estoy haciendo"
(Wernher von Braun)