Re: [HACKERS] Re: [HACKERS] generated columns - Mailing list pgsql-hackers

From Joe Conway
Subject Re: [HACKERS] Re: [HACKERS] generated columns
Date
Msg-id 89e86cfd-6d13-fedc-89ed-268c84e7116f@joeconway.com
Whole thread Raw
In response to Re: [HACKERS] generated columns  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] Re: [HACKERS] generated columns
List 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


Attachment

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: TAP test module - PostgresClient
Next
From: Gavin Flower
Date:
Subject: Re: What does Time.MAX_VALUE actually represent?