aboutsummaryrefslogtreecommitdiff
path: root/contrib/postgres_fdw/postgres_fdw.c
diff options
context:
space:
mode:
authorDean Rasheed <dean.a.rasheed@gmail.com>2023-01-30 10:04:57 +0000
committerDean Rasheed <dean.a.rasheed@gmail.com>2023-01-30 10:04:57 +0000
commitfe9e658f4d7fbc12d2b6a74c4ee90c73e53d68ef (patch)
treec28277c9bd69f22ad06dfd932d8c6dba3d58bb11 /contrib/postgres_fdw/postgres_fdw.c
parent1e8b61735cfb1a4feb72cb9ea83db690fedbfef1 (diff)
downloadpostgresql-fe9e658f4d7fbc12d2b6a74c4ee90c73e53d68ef.tar.gz
postgresql-fe9e658f4d7fbc12d2b6a74c4ee90c73e53d68ef.zip
Ensure that MERGE recomputes GENERATED expressions properly.
This fixes a bug that, under some circumstances, would cause MERGE to fail to properly recompute expressions for GENERATED STORED columns. Formerly, ExecInitModifyTable() did not call ExecInitStoredGenerated() for a MERGE command, which meant that the generated expressions information was not computed until later, when the first merge action was executed. However, if the first merge action to execute was an UPDATE, then ExecInitStoredGenerated() could decide to skip some some generated columns, if the columns on which they depended were not updated, which was a problem if the MERGE also contained an INSERT action, for which no generated columns should be skipped. So fix by having ExecInitModifyTable() call ExecInitStoredGenerated() for MERGE, and assume that it isn't safe to skip any generated columns in a MERGE. Possibly that could be relaxed, by allowing some generated columns to be skipped for a MERGE without an INSERT action, but it's not clear that it's worth the effort. Noticed while investigating bug #17759. Back-patch to v15, where MERGE was added. Dean Rasheed, reviewed by Tom Lane. Discussion: https://postgr.es/m/17759-e76d9bece1b5421c%40postgresql.org https://postgr.es/m/CAEZATCXb_ezoMCcL0tzKwRGA1x0oeE%3DawTaysRfTPq%2B3wNJn8g%40mail.gmail.com
Diffstat (limited to 'contrib/postgres_fdw/postgres_fdw.c')
0 files changed, 0 insertions, 0 deletions