aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistvalidate.c
diff options
context:
space:
mode:
authorEtsuro Fujita <efujita@postgresql.org>2022-08-05 17:15:01 +0900
committerEtsuro Fujita <efujita@postgresql.org>2022-08-05 17:15:01 +0900
commit1d49db259884a4e5579e63c05f1743608caa97b5 (patch)
treea3fee92ba8d891a997904dd5a2f39b1a6f1882cd /src/backend/access/gist/gistvalidate.c
parente78fd9084587cd485fdec3eb3eaeef567e1707d5 (diff)
downloadpostgresql-1d49db259884a4e5579e63c05f1743608caa97b5.tar.gz
postgresql-1d49db259884a4e5579e63c05f1743608caa97b5.zip
postgres_fdw: Disable batch insertion when there are WCO constraints.
When inserting a view referencing a foreign table that has WITH CHECK OPTION constraints, in single-insert mode postgres_fdw retrieves the data that was actually inserted on the remote side so that the WITH CHECK OPTION constraints are enforced with the data locally, but in batch-insert mode it cannot currently retrieve the data (except for the row first inserted through the view), resulting in enforcing the WITH CHECK OPTION constraints with the data passed from the core (except for the first-inserted row), which led to incorrect results when inserting into a view referencing a foreign table in which a remote BEFORE ROW INSERT trigger changes the rows inserted through the view so that they violate the view's WITH CHECK OPTION constraint. Also, the query inserting into the view caused an assertion failure in assert-enabled builds. Fix these by disabling batch insertion when inserting into such a view. Back-patch to v14 where batch insertion was added. Discussion: https://postgr.es/m/CAPmGK17LpbTZs4m4a_6THP54UBeK9fHvX8aVVA%2BC6yEZDZwQcg%40mail.gmail.com
Diffstat (limited to 'src/backend/access/gist/gistvalidate.c')
0 files changed, 0 insertions, 0 deletions