Re: partitioning and identity column

Peter Eisentraut <peter@eisentraut.org>

From: Peter Eisentraut <peter@eisentraut.org>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-11-13T10:21:43Z
Lists: pgsql-hackers
On 27.10.23 13:32, Ashutosh Bapat wrote:
> I think we should fix these anomalies as follows
> 1. Allow identity columns to be added to the partitioned table
> irrespective of whether they have partitions of not.
> 2. Propagate identity property to partitions.
> 3. Use the same underlying sequence for getting default value of an
> identity column when INSERTing directly in a partition.
> 4. Disallow attaching a partition with identity column.
> 
> 1 will fix inconsistencies in Behaviour 3 and 4. 2 and 3 will fix
> anomalies in Behaviour 1. 4 will fix Behaviour 2.

This makes sense to me.

Note, here is a writeup about the behavior of generated columns with 
partitioning: 
https://www.postgresql.org/docs/devel/ddl-generated-columns.html.  It 
would be useful if we documented the behavior of identity columns 
similarly.  (I'm not saying the behavior has to match.)

One thing that's not clear to me is what should happen if you have a 
partitioned table with an identity column and you try to attach a 
partition that has its own identity definition for that column.  I 
suppose we shouldn't allow that.  (The equivalent case for generated 
columns is allowed.)




Commits

  1. Fix assorted bugs related to identity column in partitioned tables

  2. Remove extra check_stack_depth() from dropconstraint_internal()

  3. Support identity columns in partitioned tables

  4. doc: Add Identity Column section under Data Definition chapter

  5. Assert that partition inherits from only one parent in MergeAttributes()

  6. doc: Decorate PostgreSQL with productname tag

  7. Fix prologue of get_partition_ancestors()