Re: [HACKERS] Re: [HACKERS] generated columns
От | Joe Conway |
---|---|
Тема | Re: [HACKERS] Re: [HACKERS] generated columns |
Дата | |
Msg-id | 50425ef7-438b-a613-c784-71e8013d14ce@joeconway.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [HACKERS] generated columns (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Re: [HACKERS] generated columns
|
Список | pgsql-hackers |
On 12/31/2017 09:38 AM, Peter Eisentraut wrote: > On 12/30/17 16:04, Joe Conway wrote: >> +<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. <snip> > Maybe some of this could be relaxed at some point, but we would have to > think it through carefully. For now, a trigger would still be the best > implementation for your use case, I think. Sure, but generated column behavior in general can be implemented via trigger. Anyway, I have seen requests for change data capture (https://en.wikipedia.org/wiki/Change_data_capture) in Postgres which is apparently available in our competition without requiring the use of triggers. Perhaps that is yet a different feature, but I was hopeful that this mechanism could be used to achieve it. -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Вложения
В списке pgsql-hackers по дате отправления: