Horton

Re: Dumping/restoring fails on inherited generated column

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>, Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-01-29T13:14:48Z
Lists: pgsql-hackers

Attachments

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/

Commits

  1. Fix ALTER TABLE / INHERIT with generated columns

  2. pg_dump: Fix dumping of inherited generated columns

  3. Disallow ALTER TABLE ONLY / DROP EXPRESSION

  4. Fix several DDL issues of generated columns versus inheritance