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-31T17:54:51Z
Lists: pgsql-hackers
On 12/31/2017 09:38 AM, Peter Eisentraut wrote: > On 12/30/17 16:04, Joe Conway wrote: >> +<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. <snip> > Maybe some of this could be relaxed at some point, but we would have to > think it through carefully. For now, a trigger would still be the best > implementation for your use case, I think. Sure, but generated column behavior in general can be implemented via trigger. Anyway, I have seen requests for change data capture (https://en.wikipedia.org/wiki/Change_data_capture) in Postgres which is apparently available in our competition without requiring the use of triggers. Perhaps that is yet a different feature, but I was hopeful that this mechanism could be used to achieve it. -- 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