Re: [HACKERS] generated columns
| От | Pavel Stehule |
|---|---|
| Тема | Re: [HACKERS] generated columns |
| Дата | |
| Msg-id | CAFj8pRAuSk=C5XQG+BwCjFZGd69twFQG_v_jNgnN+Qcr6ZEetA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] generated columns (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: [HACKERS] generated columns
|
| Список | 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
В списке pgsql-hackers по дате отправления: