On 9/12/17 15:35, Jaime Casanova wrote: > On 10 September 2017 at 00:08, Jaime Casanova > <jaime.casanova@2ndquadrant.com> wrote: >> >> During my own tests, though, i found some problems:
Here is an updated patch that should address the problems you have found.
> also is interesting that in triggers, both before and after, the > column has a null. that seems reasonable in a before trigger but not > in an after trigger
Logically, you are correct. But it seems excessive to compute all virtual columns for every trigger. I don't know how to consolidate that, especially with the current trigger API that lets you look more or less directly into the tuple.
I wasn't sure where this thought about after triggers ended up.
Presumably stored values can just be read from storage, so no overhead in after triggers?
Having the stored values show as NULL would be OK for virtual ones. But what do we do if the column is NOT NULL? Do we still have nulls then?
It would be useful to have a way to generate the values, if desired. Not sure how hard that is.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services