Re: [HACKERS] generated columns
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Jaime Casanova <jaime.casanova@2ndquadrant.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-02-01T14:29:09Z
Lists: pgsql-hackers
On 1/31/18 08:18, Michael Paquier wrote: >> This also raises a question how a row type with generated columns should >> behave. I think a generation expression is a property of a table, so it >> does not apply in a row type. (Just like a default is a property of a >> table and does not apply in row types.) > > Hm. Identity columns and default columns are part of rowtypes. STORED > columns can alsobe part of a row type with little effort, so in order to > be consistent with the all the existing behaviors, it seems to me that > virtually-generated columns should be part of it as well. I have > compiled in the attached SQL file how things behave with your > patch. Only virtually-generated columns show a blank value. > > A empty value is unhelpful for the user, which brings a couple of > possible approaches: > 1) Make virtual columns part of a row type, which would make it > consistent with all the other types. That would be nice. I'm going to study this some more to see what can be done. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Generated columns
- fc22b6623b6b 12.0 landed
-
Add walreceiver API to get remote server version
- 69039fda837d 12.0 landed
-
Add pg_partition_tree to display information about partitions
- d5eec4eefde7 12.0 cited
-
pg_restore: Augment documentation for -N option
- 2fe42baf7c1a 12.0 cited
-
Change delimiter used for display of NextXID
- 59a884e9854c 9.6.0 cited