Postgres Pro
Downloads
Home   >   mailing lists

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

From Pavel Stehule
Subject Re: [HACKERS] generated columns
Date
Msg-id CAFj8pRAuSk=C5XQG+BwCjFZGd69twFQG_v_jNgnN+Qcr6ZEetA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] generated columns  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [HACKERS] generated columns  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Tree view


út 15. 1. 2019 v 8:14 odesílatel Michael Paquier <michael@paquier.xyz> napsal:
On Sun, Jan 13, 2019 at 03:31:23PM +0100, Pavel Stehule wrote:
> ne 13. 1. 2019 v 10:43 odesílatel Peter Eisentraut <
> peter.eisentraut@2ndquadrant.com> napsal:
>> 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 wouldn't say that.  Volatibility restrictions based on immutable
functions apply to many concepts similar like expression pushdowns to
make for deterministic results.  The SQL spec takes things on the safe
side.

I would to have a mechanism for safe replacement of triggers of type

if TG_TYPE = 'INSERT' THEN
  NEW.inserted := CURRENT_TIMESTAMP;
ELSE IF TG_TYPE = 'UPDATE' THEN
  NEW.updated := CURRENT_TIMESTAMP;
 ..

But I understand, so current SQL spec design is safe.

Regards

Pavel



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] generated columns
Next
From: "Kuroda, Hayato"
Date:
Subject: RE: Log a sample of transactions