Re: [HACKERS] generated columns

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Sergei Kornilov <sk@zsrv.org>, Michael Paquier <michael.paquier@gmail.com>, Jaime Casanova <jaime.casanova@2ndquadrant.com>
Date: 2019-01-15T07:18:58Z
Lists: pgsql-hackers
ú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



>

Commits

  1. Generated columns

  2. Add walreceiver API to get remote server version

  3. Add pg_partition_tree to display information about partitions

  4. pg_restore: Augment documentation for -N option

  5. Change delimiter used for display of NextXID