From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Re: [HACKERS] generated columns |
Date: | 2017-12-30 21:04:52 |
Message-ID: | 89e86cfd-6d13-fedc-89ed-268c84e7116f@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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(dot)casanova(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Flower | 2017-12-30 21:25:40 | Re: What does Time.MAX_VALUE actually represent? |
Previous Message | Andrew Dunstan | 2017-12-30 19:35:27 | Re: TAP test module - PostgresClient |