On Feb 19, 2025 at 14:53 +0800, Michael Paquier <mich...@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
