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

From Pavel Stehule
Subject Re: [HACKERS] generated columns
Date
Msg-id CAFj8pRB=L3At5R=DXWRw7OFCdaeZ_+3S5e==DbGgD_7POsqngA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] generated columns  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] generated columns  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers


ne 13. 1. 2019 v 10:43 odesílatel Peter Eisentraut <peter.eisentraut@2ndquadrant.com> napsal:
On 11/01/2019 16:22, Pavel Stehule wrote:
> The documentation contains paragraph
>
> +      The generation expression can only use immutable functions and cannot
> +      use subqueries or reference anything other than the current row
> in any
> +      way.
>
> It is necessary for stored columns?

See here:
https://www.postgresql.org/message-id/b5c27634-1d44-feba-7494-ce5a31f914ca@2ndquadrant.com

I understand - it is logical. But it is sad, so this feature is not complete. The benefit is not too big - against functional indexes or views. But it can be first step.



> I tested it with pseudo constant - current_timestamp, session_user. But
> current_database() is disallowed.
>
> on second hand, this is strange
>
> postgres=# create table foo3 (inserted text generated always as
> (current_timestamp) virtual);
> CREATE TABLE

Ah, the volatility checking needs some improvements.  I'll address that
in the next patch version.

ok
 
--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Three animals fail test-decoding-check on REL_10_STABLE
Next
From: Andrew Dunstan
Date:
Subject: Re: Three animals fail test-decoding-check on REL_10_STABLE