Generated Columns

[theblinkingusb]

Hey team - thanks for this repo.

RE Migrations - any thoughts around ignoring generated columns if created on the secondary table? ie. adding AND attgenerated = '' in the pg_attribute selects for holder and commonColumns for the history selects (link to relevant PG attr docs).

Today I had to change some of the current/history tables and add computed columns for performance reasons. On adding those columns the inserts into the base table failed - here's an example if desired

CREATE TABLE subscriptions
(
  name text NOT NULL,
  changed_value text not null
);

ALTER TABLE subscriptions
  ADD COLUMN sys_period tstzrange NOT NULL DEFAULT tstzrange(current_timestamp, null);

CREATE TABLE subscriptions_history (LIKE subscriptions);

CREATE TRIGGER versioning_trigger
BEFORE INSERT OR UPDATE OR DELETE ON subscriptions
FOR EACH ROW EXECUTE PROCEDURE versioning(
  'sys_period', 'subscriptions_history', true
);
--works fine
insert into subscriptions (name, changed_value) values ('sub_ab', 'value1');
select * from subscriptions; 

-- change dimension
alter table subscriptions  add name_cleaned text  generated always as (upper(name)) stored;
alter table subscriptions_history add name_cleaned text  generated always as (upper(name)) stored;

-- fails
update subscriptions set changed_value = 'value_2' where name = 'sub_ab'

I could argue either on this edge case but possibly we can add some advice to the docs under Migrations regarding this.

Thanks

[ovhemert]

We would like to keep the functionality generic and close to existing C extensions. I believe the generated columns would over complicate things and will add additional edge cases with data compares.