Re: Proposal to CREATE FOREIGN TABLE LIKE

On Feb 18, 2025 at 08:49 +0800, Michael Paquier <michael(at)paquier(dot)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(at)paquier(dot)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