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
