On Sat, Jul 3, 2021 at 7:44 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> But rather
> than computing the generated columns locally, I’m wondering that we
> should compute them remotely, assuming that the corresponding
> generated columns are defined on the remote sides. (It would be the
> user’s responsibility to ensure that.) This seems to me similar to
> the constraint case, and if we did so, I think we could fix the
> reported issue by extending postgresImportForeignSchema to support
> generated columns.
I updated the patch as such:
* Modified nodeModifyTable.c and copyfrom.c so that they don't compute
generated columns for FDWs anymore.
* Modified deparse functions such as deparseInsertSql() so that the
query is deparsed to set target generated columns (if any) to DEFAULT.
* Added an option import_generated to postgres_fdw to support
importing generated columns.
* Added a bit more test cases to postgres_fdw.sql.
* Updated docs.
Currently, foreign tables are not allowed to be updated directly when
they have stored generated columns, but I think they could be. But I
left that as future work as that would be an improvement rather than a
fix.
Attached is an updated version of the patch.
Best regards,
Etsuro Fujita