Re: Proposal to CREATE FOREIGN TABLE LIKE

On Feb 19, 2025 at 14:53 +0800, Michael Paquier <michael(at)paquier(dot)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