aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-11-22 15:25:48 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2021-11-22 15:25:48 -0500
commit0b126c6a4b00972f2f3533e1718bbe297e2851c2 (patch)
treeb4967fb2614062f2f27fe260b02c0b801120ddd9 /src/backend/executor
parentc4fe3199a6d65212537a59eb0d7e6fad22b9e903 (diff)
downloadpostgresql-0b126c6a4b00972f2f3533e1718bbe297e2851c2.tar.gz
postgresql-0b126c6a4b00972f2f3533e1718bbe297e2851c2.zip
Fix pg_dump --inserts mode for generated columns with dropped columns.
If a table contains a generated column that's preceded by a dropped column, dumpTableData_insert failed to account for the dropped column, and would emit DEFAULT placeholder(s) in the wrong column(s). This resulted in failures at restore time. The default COPY code path did not have this bug, likely explaining why it wasn't noticed sooner. While we're fixing this, we can be a little smarter about the situation: (1) avoid unnecessarily fetching the values of generated columns, (2) omit generated columns from the output, too, if we're using --column-inserts. While these modes aren't expected to be as high-performance as the COPY path, we might as well be as efficient as we can; it doesn't add much complexity. Per report from Дмитрий Иванов. Back-patch to v12 where generated columns came in. Discussion: https://postgr.es/m/CAPL5KHrkBniyQt5e1rafm5DdXvbgiiqfEQEJ9GjtVzN71Jj5pA@mail.gmail.com
Diffstat (limited to 'src/backend/executor')
0 files changed, 0 insertions, 0 deletions