Horton

Thread

Commits

  1. Add support for LIKE in CREATE FOREIGN TABLE

  1. Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-01T06:55:12Z

    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 Cloudberry,
and we often need to create foreign tables that match the column definitions of local tables.

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

And since Postgres doesn’t enforce constraints on foreign tables, it’s up to the user to make sure the constraints match the actual data.
https://www.postgresql.org/docs/current/sql-createforeigntable.html

This means that enabling CREATE FOREIGN TABLE LIKE shouldn’t introduce more issues with constraints

I haven’t rush with the codes yet, but it seems like it could be straightforward to implement by tweaking the existing limitations:

```
static void
transformTableLikeClause(CreateStmtContext *cxt, TableLikeClause *table_like_clause)
{
	...
	if (cxt->isforeign)
		ereport(ERROR,
				(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
				 errmsg("LIKE is not supported for creating foreign tables")));
}
```

with some test cases and Documents changes.


Zhang Mingli
www.hashdata.xyz

  2. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2025-02-01T12:20:17Z

    On 2025-Feb-01, Zhang Mingli wrote:

> Our DBA team uses foreign tables for ETL processes in Greenplum and Cloudberry,
> and we often need to create foreign tables that match the column definitions of local tables.
> 
> When dealing with wide tables and lots of those foreign tables, it can get pretty tedious and mistakes happen easily.

Sure.  Did you consider IMPORT FOREIGN SCHEMA?

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
[…] indem ich in meinem Leben oft an euch gedacht, euch glücklich zu machen. Seyd es!
A menudo he pensado en vosotros, en haceros felices. ¡Sedlo, pues!
		Heiligenstädter Testament, L. v. Beethoven, 1802
		https://de.wikisource.org/wiki/Heiligenstädter_Testament

  3. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-01T13:39:10Z

    
Zhang Mingli
www.hashdata.xyz
On Feb 1, 2025 at 20:20 +0800, Álvaro Herrera <alvherre@alvh.no-ip.org>, wrote:
>
> Sure. Did you consider IMPORT FOREIGN SCHEMA?
Hi, Álvaro

Thank you very much for your suggestion.

I've looked into it, and it certainly can be beneficial, especially for postgres_fdw.
However, I believe that not all FDWs support the concept of a schema or can be used with the IMPORT FOREIGN SCHEMA command, is it?


For example, we use kafka_fdw to produce and consume data from a Kafka server.
In our scenario, we sometimes need to write records from a local table into Kafka. Here’s a brief outline of our process:

1. We already have a wide table, local_wide_table in Postgres.
2. We need to create a foreign table, foreign_table, with the same definition as local_wide_table.
3. Insert records into foreign_table by selecting from local_wide_table with the some quals.

In step 2, we currently have to manually create the foreign table using CREATE FOREIGN TABLE and copy the column definitions one by one.

  4. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2025-02-02T13:24:29Z

    On 2025-Feb-01, Zhang Mingli wrote:

> For example, we use kafka_fdw to produce and consume data from a Kafka
> server.  In our scenario, we sometimes need to write records from a
> local table into Kafka. Here’s a brief outline of our process:
> 
> 1. We already have a wide table, local_wide_table in Postgres.
> 2. We need to create a foreign table, foreign_table, with the same
> definition as local_wide_table.
> 3. Insert records into foreign_table by selecting
> from local_wide_table with the some quals.
> 
> In step 2, we currently have to manually create the foreign table
> using CREATE FOREIGN TABLE and copy the column definitions one by one.

Eh yeah, I guess for this use case it makes sense to allow a LIKE clause
on CREATE FOREIGN TABLE.  Were you going to submit a patch?

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Having your biases confirmed independently is how scientific progress is
made, and hence made our great society what it is today" (Mary Gardiner)

  5. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-02T22:22:13Z

    Zhang Mingli
www.hashdata.xyz
On Feb 2, 2025 at 21:24 +0800, Álvaro Herrera <alvherre@alvh.no-ip.org>,
wrote:


Eh yeah, I guess for this use case it makes sense to allow a LIKE clause
on CREATE FOREIGN TABLE. Were you going to submit a patch?

Hi,

Yes, I would like to provide a patch.

Glad to see we have come to an agreement on this.

  6. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Michael Paquier <michael@paquier.xyz> — 2025-02-03T00:29:17Z

    On Mon, Feb 03, 2025 at 06:22:13AM +0800, Mingli Zhang wrote:
> Yes, I would like to provide a patch.
> 
> Glad to see we have come to an agreement on this.

Just adding my +1 here.  FWIW.
--
Michael

  7. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-06T10:09:42Z

    On Feb 3, 2025 at 08:29 +0800, Michael Paquier <michael@paquier.xyz>, wrote:
> On Mon, Feb 03, 2025 at 06:22:13AM +0800, Mingli Zhang wrote:
> > Yes, I would like to provide a patch.
> >
> > Glad to see we have come to an agreement on this.
>
> Just adding my +1 here. FWIW.
Hi,

Patch added.

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 have disallowed the COMPRESSION option due to existing inconsistencies between STORAGE and COMPRESSION.
I’ve posted a summary of these issues at Inconsistency between Compression and Storage for Foreign Tables[0].

Once we align the behavior of STORAGE and COMPRESSION, I believe that COMPRESSION should also be copied for foreign tables, similar to STORAGE.
This might be beneficial for foreign data wrappers (FDWs) that take it into account.


[0] https://www.postgresql.org/message-id/6cecef0e-ee14-473c-bb0a-6aa61f539a66%40Spark

--
Zhang Mingli
HashData

  8. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2025-02-06T10:29:18Z

    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.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

  9. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2025-02-06T10:31:43Z

    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)

  10. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-06T12:13:47Z

    On Feb 6, 2025 at 18:31 +0800, Álvaro Herrera <alvherre@alvh.no-ip.org>, wrote:
>
> 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.
Hi, Yeah,

Our current convention is to ignore any inapplicable options without throwing errors.

As you mentioned, we use bits to identify the options, which does add some complexity to the codes if we try to track the origin of the option bits.

--
Zhang Mingli
HashData

  11. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-07T14:24:36Z

    On Feb 6, 2025 at 18:09 +0800, Zhang Mingli <zmlpostgres@gmail.com>, wrote:
> On Feb 3, 2025 at 08:29 +0800, Michael Paquier <michael@paquier.xyz>, wrote:
> > On Mon, Feb 03, 2025 at 06:22:13AM +0800, Mingli Zhang wrote:
> > > Yes, I would like to provide a patch.
> > >
> > > Glad to see we have come to an agreement on this.
> >
> > Just adding my +1 here. FWIW.
> Hi,
>
> Patch added.

Add it to commitfest: https://commitfest.postgresql.org/52/5557

--
Zhang Mingli
HashData

  12. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-07T16:50:47Z

    On Feb 7, 2025 at 22:24 +0800, Zhang Mingli <zmlpostgres@gmail.com>, wrote:
> On Feb 6, 2025 at 18:09 +0800, Zhang Mingli <zmlpostgres@gmail.com>, wrote:
> > On Feb 3, 2025 at 08:29 +0800, Michael Paquier <michael@paquier.xyz>, wrote:
> > > On Mon, Feb 03, 2025 at 06:22:13AM +0800, Mingli Zhang wrote:
> > > > Yes, I would like to provide a patch.
> > > >
> > > > Glad to see we have come to an agreement on this.
> > >
> > > Just adding my +1 here. FWIW.
> > Hi,
> >
> > Patch added.
>
> Add it to commitfest: https://commitfest.postgresql.org/52/5557

Fix CI failure of doc build in v1 patch.

--
Zhang Mingli
HashData

  13. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Sami Imseih <samimseih@gmail.com> — 2025-02-08T04:55:23Z

    > Fix CI failure of doc build in v1 patch.

Thanks for the patch! I am +1 for this, but I have a few comments:

1/ In the IDENTITY case, the remote side may not be
able to handle the DEFAULT value. See the example below:

-- on the foreign server
postgres=# CREATE TABLE t2 (id int, c1 text);
CREATE TABLE

-- on the local server
postgres=#
postgres=# CREATE TABLE t1 (id int GENERATED ALWAYS AS IDENTITY, c1 text);
CREATE TABLE
postgres=# CREATE FOREIGN TABLE t2 (LIKE t1 INCLUDING INDEXES) server r1;
CREATE FOREIGN TABLE
postgres=# INSERT INTO t2 (c1) VALUES ('A');
INSERT 0 1
postgres=# SELECT * FROM t2;
 id | c1
----+----
    | A
(1 row)

This is also the reason foreign tables don't document IDENTITY as valid [1].
It may even be a bug for it to be allowed with the CREATE FOREIGN TABLE
syntax:

postgres=# CREATE FOREIGN TABLE t3 (id int GENERATED ALWAYS AS
IDENTITY, c1 text) server r1;
CREATE FOREIGN TABLE
postgres=# \d+ t3
                                                  Foreign table "public.t3"
 Column |  Type   | Collation | Nullable |           Default
 | FDW options | Storage  | Stats target | Description
--------+---------+-----------+----------+------------------------------+-------------+----------+--------------+-------------
 id     | integer |           | not null | generated always as
identity |             | plain    |              |
 c1     | text    |           |          |
 |             | extended |              |
Not-null constraints:
    "t3_id_not_null" NOT NULL "id"
Server: r1

2/  As IDENTITY, STORAGE is also allowed on foreign tables, which
does not make much sense either, as the fdw may not be Postgres,
or if it is Postgres, it may have a different STORAGE setting. This is
also not documented. I am inclined to say to not include it either.

I think we should not allow IDENTITY and STORAGE in this patch
as they are not documented [1] as is, and perhaps a separate discussion
to correct the behavior for the CREATE FOREIGN TABLE case.

3/ a minor nit on the comments.

instead of

+      Foreign tables have no real storage in PostgreSQL.

Can it just be

Foreign tables have no storage in PostgreSQL.

the "real" is not needed.

[1] https://www.postgresql.org/docs/current/sql-createforeigntable.html

--
Regards,

Sami

  14. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-09T13:16:53Z

    On Feb 8, 2025 at 12:55 +0800, Sami Imseih <samimseih@gmail.com>, wrote:
> > Fix CI failure of doc build in v1 patch.
> >
> > Thanks for the patch! I am +1 for this, but I have a few comments:
Hi, tanks for review.
> >
> > 1/ In the IDENTITY case, the remote side may not be
> > able to handle the DEFAULT value.
Yes, and done.
> > 2/ As IDENTITY, STORAGE is also allowed on foreign tables, which
> > does not make much sense either, as the fdw may not be Postgres,
> > or if it is Postgres, it may have a different STORAGE setting. This is
> > also not documented. I am inclined to say to not include it either.
Done.
> >
> > I think we should not allow IDENTITY and STORAGE in this patch
> > as they are not documented [1] as is, and perhaps a separate discussion
> > to correct the behavior for the CREATE FOREIGN TABLE case.
Yes, however, I found we have doc to tell users and they actually could ALTER FOREIGN TABLE to SET STORAGE...
There are several inconsistencies, I have a summary in Inconsistency between Compression and Storage for Foreign Tables[0]
We could discuss and fix them there.
> >
> > 3/ a minor nit on the comments.
> >
> > instead of
> >
> > + Foreign tables have no real storage in PostgreSQL.
> >
> > Can it just be
> >
> > Foreign tables have no storage in PostgreSQL.
> >
> > the "real" is not needed.
Done.

Patch V2 addressed the comments.


[0] https://www.postgresql.org/message-id/6cecef0e-ee14-473c-bb0a-6aa61f539a66%40Spark


--
Zhang Mingli
HashData

  15. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Sami Imseih <samimseih@gmail.com> — 2025-02-11T00:14:14Z

    > Patch V2 addressed the comments.

Overall this LGTM.

I still see a "no real storage" in v2 that should be removed
from the documentation.

+ Foreign tables have no real storage in PostgreSQL.
+ Inapplicable options: <literal>INCLUDING INDEXES</literal>,
<literal>INCLUDING STORAGE</literal>,

I think the test coverage to check for the negative conditions only is
enough.

Regards,

Sami

  16. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-11T14:49:24Z

    On Feb 11, 2025 at 08:14 +0800, Sami Imseih <samimseih@gmail.com>, wrote:
> > Patch V2 addressed the comments.
> >
> > Overall this LGTM.
> >
> > I still see a "no real storage" in v2 that should be removed
> > from the documentation.
> >
> > + Foreign tables have no real storage in PostgreSQL.
> > + Inapplicable options: <literal>INCLUDING INDEXES</literal>,
> > <literal>INCLUDING STORAGE</literal>,
Oh, I corrected another one in the code comments, but I forgot about this one.
Done in patch v3.
>
>
> I think the test coverage to check for the negative conditions only is
> enough.

Hmm... I copied from the cases in the same file for each option.
There's no harm in having more tests, how about we keep them?

--
Zhang Mingli
HashData

  17. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Sami Imseih <samimseih@gmail.com> — 2025-02-11T16:07:48Z

    > + Foreign tables have no real storage in PostgreSQL.
> + Inapplicable options: <literal>INCLUDING INDEXES</literal>,
> <literal>INCLUDING STORAGE</literal>,
>
> Oh, I corrected another one in the code comments, but I forgot about this one.
> Done in patch v3.

I attached v4 with some slight modifications to the wording, otherwise
this looks good.

>> I think the test coverage to check for the negative conditions only is
>> enough.
>>
>>
> Hmm... I copied from the cases in the same file for each option.
> There's no harm in having more tests, how about we keep them?

I agree. I was just saying the test cases you provided are
enough. No changes needed for the tests.

I have no further comments.

Regards,

Sami

  18. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Michael Paquier <michael@paquier.xyz> — 2025-02-17T07:23:56Z

    On Tue, Feb 11, 2025 at 10:07:48AM -0600, Sami Imseih wrote:
> I agree. I was just saying the test cases you provided are
> enough. No changes needed for the tests.
> 
> I have no further comments.

The checks you are adding in the parse analysis of the LIKE clauses is
surprisingly light.

+ * For foreign tables, they have no storage in Postgres.
+ * Inapplicable options are ignored.

Wording is a bit strange here.

+ *	CREATE_TABLE_LIKE_COMPRESSION
+ *	CREATE_TABLE_LIKE_IDENTITY
+ *	CREATE_TABLE_LIKE_STORAGE
+ *	CREATE_TABLE_LIKE_INDEXES
[...]
+DROP FOREIGN TABLE ctl_foreign_table1;
+DROP FOREIGN TABLE ctl_foreign_table2;
+DROP FOREIGN TABLE ctl_foreign_table3;
+DROP FOREIGN TABLE ctl_foreign_table4;
+DROP FOREIGN TABLE ctl_foreign_table5;
+DROP FOREIGN TABLE ctl_foreign_table6;

What's the point of creating that many tables, one for each of the
four INCLUDING options you are testing?  It is possible to stack all
of them in a single CREATE TABLE command, still is that really
necessary if we have coverage with INCLUDING ALL and EXCLUDING ALL
(perhaps write it directly in the CREATE query rather than assume that
it is the default) as these are all-or-nothing switches for all the
option values.  Of course let's be careful with HIDE_TOAST_COMPRESSION
if need be.

Perhaps the original table should have a primary key, also to track
the fact that the NOT NULL constraint is always copied but its related
index is not?  Identity columns assign a NOT NULL constraint, as
documented these are always copied.  Just wanted to point out that
this works the same way for your implementation with foreign tables, 
so perhaps we should have a test for that.

Glad to see that you did not forget about statistics.  I didn't recall
that these were OK for foreign tables, TBH.

expandTableLikeClause() depends on the "constr" built in the first
phase of transformTableLikeClause() to bypass the parts related to
generated, default and constraints properties.  This dependency
between both routines should be documented, I guess.  Hmm..  Not sure
where.
--
Michael

  19. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-17T11:14:59Z

    On Feb 17, 2025 at 15:24 +0800, Michael Paquier <michael@paquier.xyz>, wrote:
>
> + * For foreign tables, they have no storage in Postgres.
> + * Inapplicable options are ignored.
>
> Wording is a bit strange here.
Hi, is this better?


 * Foreign tables do not store data in Postgres.
 * Any options that are not applicable for foreign tables will be ignored:

> + * CREATE_TABLE_LIKE_COMPRESSION
> + * CREATE_TABLE_LIKE_IDENTITY
> + * CREATE_TABLE_LIKE_STORAGE
> + * CREATE_TABLE_LIKE_INDEXES
> [...]
> +DROP FOREIGN TABLE ctl_foreign_table1;
> +DROP FOREIGN TABLE ctl_foreign_table2;
> +DROP FOREIGN TABLE ctl_foreign_table3;
> +DROP FOREIGN TABLE ctl_foreign_table4;
> +DROP FOREIGN TABLE ctl_foreign_table5;
> +DROP FOREIGN TABLE ctl_foreign_table6;
>
> What's the point of creating that many tables, one for each of the
> four INCLUDING options you are testing? It is possible to stack all
> of them in a single CREATE TABLE command, still is that really
> necessary if we have coverage with INCLUDING ALL and EXCLUDING ALL
> (perhaps write it directly in the CREATE query rather than assume that
> it is the default) as these are all-or-nothing switches for all the
> option values. Of course let's be careful with HIDE_TOAST_COMPRESSION
> if need be.

I usually follow the cases within the same file; for each independent option, it becomes easier to identify which options are valid or invalid.
However, if you believe consolidating them into one is better, I’m fine with that. Updated.
> Perhaps the original table should have a primary key, also to track
> the fact that the NOT NULL constraint is always copied but its related
> index is not? Identity columns assign a NOT NULL constraint, as
> documented these are always copied. Just wanted to point out that
> this works the same way for your implementation with foreign tables,
> so perhaps we should have a test for that.
Done, although there is already one in column d.
>
> Glad to see that you did not forget about statistics. I didn't recall
> that these were OK for foreign tables, TBH.
I also didn't realize this until I wrote this patch. This could be useful for the planner？

> expandTableLikeClause() depends on the "constr" built in the first
> phase of transformTableLikeClause() to bypass the parts related to
> generated, default and constraints properties. This dependency
> between both routines should be documented, I guess. Hmm.. Not sure
> where.
Comments are addressed except for this one, it might be worth considering another patch.

--
Zhang Mingli
HashData

  20. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Michael Paquier <michael@paquier.xyz> — 2025-02-18T00:49:22Z

    On Mon, Feb 17, 2025 at 07:14:59PM +0800, Zhang Mingli wrote:
> On Feb 17, 2025 at 15:24 +0800, Michael Paquier <michael@paquier.xyz>, wrote:
>> + * For foreign tables, they have no storage in Postgres.
>> + * Inapplicable options are ignored.
>>
>> Wording is a bit strange here.
> 
>  * Foreign tables do not store data in Postgres.
>  * Any options that are not applicable for foreign tables will be ignored:

I would do something like that, perhaps, though I could get that
people don't like this suggestion:
"Some options are ignored.  For example, as foreign tables have no
storage, these options have no effect: storage, compression, identity
and indexes.  Similarly, INCLUDING INDEXES is ignored from a view."

> I usually follow the cases within the same file; for each
> independent option, it becomes easier to identify which options are
> valid or invalid.  However, if you believe consolidating them into
> one is better, I’m fine with that. Updated.

It does not matter much in this case, IMO, what matters is to make
sure that the four additional checks you are adding in the
post-parsing paths are correctly ignored.  Passing down an INCLUDING
ALL does that just fine as you double-check the state of the table
with a \d+ meta-command.

> I also didn't realize this until I wrote this patch. This could be
> useful for the planner？

Constraints can be used as hints in the planner when working on
foreign tables.  I'm pretty sure that this is the same reason here,
seeing that this is supported since v10 where statistics have been
introduced.  I would need to dig more into the code, but that's not
really the point for this thread..

>> expandTableLikeClause() depends on the "constr" built in the first
>> phase of transformTableLikeClause() to bypass the parts related to
>> generated, default and constraints properties. This dependency
>> between both routines should be documented, I guess. Hmm.. Not sure
>> where.
>
> Comments are addressed except for this one, it might be worth
> considering another patch.

Yeah, not entirely sure.  It does not prevent your patch to work, and
it is already documented that the "expand" part is done as-is because
it depends on the "transform".  So perhaps it's just OK like this.  I
withdraw my comment.

+      Inapplicable options: <literal>INCLUDING INDEXES</literal>, <literal>INCLUDING STORAGE</literal>,
+      <literal>INCLUDING COMPRESSION</literal>, <literal>INCLUDING IDENTITY</literal> are ignored.

I would remove this paragraph, actually.  The options supported are
listed by your patch, and that would be one area less to update if a
new INCLUDING flavor is added.

Copy-pasting the details of how the LIKE options work to the
create_foreign_table.sgml page is OK for me, and perhaps this will
diverge a bit from the CREATE TABLE part.  One thing is that LIKE is
not part of the SQL specification for CREATE FOREIGN TABLE.  Perhaps
this should be mentioned at the bottom of the page under the
"compatibility" section?
--
Michael

  21. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-18T01:54:51Z

    On Feb 18, 2025 at 08:49 +0800, Michael Paquier <michael@paquier.xyz>, wrote:
> On Mon, Feb 17, 2025 at 07:14:59PM +0800, Zhang Mingli wrote:
> > On Feb 17, 2025 at 15:24 +0800, Michael Paquier <michael@paquier.xyz>, wrote:
> > > + * For foreign tables, they have no storage in Postgres.
> > > + * Inapplicable options are ignored.
> > >
> > > Wording is a bit strange here.
> >
> >  * Foreign tables do not store data in Postgres.
> >  * Any options that are not applicable for foreign tables will be ignored:
>
> I would do something like that, perhaps, though I could get that
> people don't like this suggestion:
> "Some options are ignored. For example, as foreign tables have no
> storage, these options have no effect: storage, compression, identity
> and indexes. Similarly, INCLUDING INDEXES is ignored from a view."
OK.
> > I also didn't realize this until I wrote this patch. This could be
> > useful for the planner？
>
> Constraints can be used as hints in the planner when working on
> foreign tables. I'm pretty sure that this is the same reason here,
> seeing that this is supported since v10 where statistics have been
> introduced. I would need to dig more into the code, but that's not
> really the point for this thread..
Agree.
> + Inapplicable options: <literal>INCLUDING INDEXES</literal>, <literal>INCLUDING STORAGE</literal>,
> + <literal>INCLUDING COMPRESSION</literal>, <literal>INCLUDING IDENTITY</literal> are ignored.
>
> I would remove this paragraph, actually. The options supported are
> listed by your patch, and that would be one area less to update if a
> new INCLUDING flavor is added.
OK.
>
> Copy-pasting the details of how the LIKE options work to the
> create_foreign_table.sgml page is OK for me, and perhaps this will
> diverge a bit from the CREATE TABLE part. One thing is that LIKE is
> not part of the SQL specification for CREATE FOREIGN TABLE. Perhaps
> this should be mentioned at the bottom of the page under the
> "compatibility" section?
Good point.

Will address the comments later,  thanks for review!

--
Zhang Mingli
HashData

  22. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-18T12:07:18Z

    On Feb 18, 2025 at 09:54 +0800, Zhang Mingli <zmlpostgres@gmail.com>, wrote:
>
> Will address the comments later,  thanks for review!

Done in patch v6.

--
Zhang Mingli
HashData

  23. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-18T12:43:02Z

    On Feb 18, 2025 at 09:54 +0800, Zhang Mingli <zmlpostgres@gmail.com>, wrote:
>
> Will address the comments later,  thanks for review!

Done in patch v6.

--
Zhang Mingli
HashData

  24. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Michael Paquier <michael@paquier.xyz> — 2025-02-19T06:53:11Z

    On Tue, Feb 18, 2025 at 08:43:02PM +0800, Zhang Mingli wrote:
> On Feb 18, 2025 at 09:54 +0800, Zhang Mingli <zmlpostgres@gmail.com>, wrote:
> >
> > Will address the comments later,  thanks for review!
> 
> Done in patch v6.

There was a hole in the tests for the option LIKE_STORAGE.  Removing
the check for it in transformTableLikeClause() did now show a diff in
the tests.  In the case of foreign tables, extended for storage is a
correct choice when using a text type for an attribute.  It makes more
sense to use something like "main" on the origin table, then check
that the foreign table uses "extended", for example.

\d+ for a foreign table has no compression field, so using
HIDE_TOAST_COMPRESSION has no meaning.  Removing the check for the
option LIKE_COMPRESSION leads to no diffs in the regression tests.

The other two restrictions for indexes and identity were OK.

The docs are fine after a closer look, relying mostly on the clauses
supported by the CREATE FOREIGN TABLE command, tweaked a bit the part
at the bottom where LIKE is not part of the standard.

And applied.
--
Michael

  25. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-02-19T07:40:56Z

    On Feb 19, 2025 at 14:53 +0800, Michael Paquier <michael@paquier.xyz>, wrote:
> There was a hole in the tests for the option LIKE_STORAGE. Removing
> the check for it in transformTableLikeClause() did now show a diff in
> the tests. In the case of foreign tables, extended for storage is a
> correct choice when using a text type for an attribute. It makes more
> sense to use something like "main" on the origin table, then check
> that the foreign table uses "extended", for example.
You're right.
That was my mistake when I squashed the independent `like_options` cases into the two cases (`INCLUDING ALL`/`EXCLUDING ALL`) ,
particularly where there is an `ALTER STORAGE` before creating the foreign table, which shows the STORAGE difference.
Thanks for the correction.
> \d+ for a foreign table has no compression field, so using
> HIDE_TOAST_COMPRESSION has no meaning. Removing the check for the
> option LIKE_COMPRESSION leads to no diffs in the regression tests.
>
> The other two restrictions for indexes and identity were OK.
>
> The docs are fine after a closer look, relying mostly on the clauses
> supported by the CREATE FOREIGN TABLE command, tweaked a bit the part
> at the bottom where LIKE is not part of the standard.
>
> And applied.
Thanks.

--
Zhang Mingli
HashData

  26. Re: Proposal to CREATE FOREIGN TABLE LIKE

    Michael Paquier <michael@paquier.xyz> — 2025-02-19T23:55:51Z

    On Wed, Feb 19, 2025 at 03:40:56PM +0800, Zhang Mingli wrote:
> Thanks for the correction.

No problem.  If you see anything else that you think is misleading,
please feel free to ping me on this thread.
--
Michael