PG Bug reporting form <noreply@postgresql.org> writes:
> pg_dump does not wite DEFAULT for generated columns. So, it produces error
> when restoring.
It works fine for me, and if it didn't work fine for other people
we'd have had a lot of other bug reports by now. Please provide
a concrete example.
> The strange part is that when I create the table again, fill it with data
> and use pg_dump to bacup, it is correct, but the current table in the
> database producecs wrong backup.
Hmm ... what minor release of pg_dump are you using? I wonder if
you are hitting the bug fixed here:
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_15_BR [0b126c6a4] 2021-11-22 15:25:48 -0500
Branch: REL_14_STABLE Release: REL_14_2 [aedc4600d] 2021-11-22 15:25:48 -0500
Branch: REL_13_STABLE Release: REL_13_6 [6fc8b145e] 2021-11-22 15:25:48 -0500
Branch: REL_12_STABLE Release: REL_12_10 [1e7f588ad] 2021-11-22 15:25:48 -0500
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.
regards, tom lane
