Re: [HACKERS] generated columns

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: michael(at)paquier(dot)xyz
Cc: peter(dot)eisentraut(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org, michael(dot)paquier(at)gmail(dot)com, jaime(dot)casanova(at)2ndquadrant(dot)com
Subject: Re: [HACKERS] generated columns
Date: 2018-11-15 16:48:52
Message-ID: CADkLM=d+Jiz8fGxw+HaYE8zjZvpZrRvVtke-77p5G2Q0v7DSZg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> > 3. Radical alternative: Collapse everything into one new column. We
> > could combine atthasdef and attgenerated and even attidentity into a new
> > column. (Only one of the three can be the case.) This would give
> > client code a clean break, which may or may not be good. The
> > implementation would be uglier than #1 but probably cleaner than #2. We
> > could also get 4 bytes back per pg_attribute row.
> >
> > I'm happy with the current choice #1, but it's worth thinking about.
>
> #3 looks very appealing in my opinion as those columns have no overlap,
> so it would take five possible values:
>

Could the removed columns live on...as generated-always columns?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-11-15 18:44:43 Re: wal_dump output on CREATE DATABASE
Previous Message Alvaro Herrera 2018-11-15 15:33:35 Re: pgsql: Add flag values in WAL description to all heap records