Re: [HACKERS] Re: [HACKERS] generated columns
Joe Conway <mail@joeconway.com>
From: Joe Conway <mail@joeconway.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Jaime Casanova <jaime.casanova@2ndquadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-12-30T21:04:52Z
Lists: pgsql-hackers
On 12/27/2017 09:31 AM, Peter Eisentraut wrote: > On 9/12/17 15:35, Jaime Casanova wrote: >> On 10 September 2017 at 00:08, Jaime Casanova >> <jaime.casanova@2ndquadrant.com> wrote: >>> >>> During my own tests, though, i found some problems: > > Here is an updated patch that should address the problems you have found. In the commit message it says: "The plan to is implement two kinds of generated columns: virtual (computed on read) and stored (computed on write). This patch only implements the virtual kind, leaving stubs to implement the stored kind later." and in the patch itself: +<para> + The generation expression can refer to other columns in the table, but + not other generated columns. Any functions and operators used must be + immutable. References to other tables are not allowed. +</para> Question -- when the "stored" kind of generated column is implemented, will the immutable restriction be relaxed? I would like, for example, be able to have a stored generated column that executes now() whenever the row is written/rewritten. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Commits
-
Generated columns
- fc22b6623b6b 12.0 landed
-
Add walreceiver API to get remote server version
- 69039fda837d 12.0 landed
-
Add pg_partition_tree to display information about partitions
- d5eec4eefde7 12.0 cited
-
pg_restore: Augment documentation for -N option
- 2fe42baf7c1a 12.0 cited
-
Change delimiter used for display of NextXID
- 59a884e9854c 9.6.0 cited