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
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 |