Re: [HACKERS] generated columns

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>
Subject: Re: [HACKERS] generated columns
Date: 2018-11-22 15:20:20
Message-ID: 9881dbb2-e0ec-8e75-27ca-7b049894aec2@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 19/11/2018 19:54, Alvaro Herrera wrote:
> It's unclear why you made generated columns on partitions unsupported.
> I'd fix the limitation if possible, but if not, at least document it.

This is explained here:

+ /*
+ * Generated columns in partition key expressions:
+ *
+ * - Stored generated columns cannot work: They are computed
+ * after BEFORE triggers, but partition routing is done
+ * before all triggers.
+ *
+ * - Virtual generated columns could work. But there is a
+ * problem when dropping such a table: Dropping a table
+ * calls relation_open(), which causes partition keys to be
+ * constructed for the partcache, but at that point the
+ * generation expression is already deleted (through
+ * dependencies), so this will fail. So if you remove the
+ * restriction below, things will appear to work, but you
+ * can't drop the table. :-(
+ */

> (I particularly notice that partition key is marked as unsupported in
> the regression test. Consider partitioning on a SERIAL column, this is
> clearly something that users will expect to work.)

A serial column is not a generated column.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2018-11-22 16:09:58 Re: dsa_allocate() faliure
Previous Message Peter Eisentraut 2018-11-22 15:16:34 Re: [HACKERS] generated columns