| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Dumping/restoring fails on inherited generated column |
| Date: | 2021-01-29 13:14:48 |
| Message-ID: | 41888c80-e5bd-f9e5-75dc-fb377113168c@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I've had another go at this, and I've found a solution that appears to
address all the issues I'm aware of. It's all very similar to the
previously discussed patches. The main difference is that previous
patches had attempted to use something like tbinfo->attislocal to
determine whether a column was inherited, but that's not correct. This
patch uses the existing logic in flagInhAttrs() to find whether there is
a matching parent column with a generation expression. I've added
pg_dump test cases here to check the different variations that the code
addresses.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
| Attachment | Content-Type | Size |
|---|---|---|
| v4-0001-pg_dump-Fix-dumping-of-inherited-generated-column.patch | text/plain | 8.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2021-01-29 13:18:09 | Re: Allow matching whole DN from a client certificate |
| Previous Message | Daniel Gustafsson | 2021-01-29 13:13:30 | Re: Support for NSS as a libpq TLS backend |