Re: [HACKERS] generated columns

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Sergei Kornilov <sk(at)zsrv(dot)org>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>
Subject: Re: [HACKERS] generated columns
Date: 2019-03-20 02:51:03
Message-ID: 20190320025103.GG3488@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 18, 2019 at 03:14:09PM +0100, Pavel Stehule wrote:
> postgres=# update foo set name = 'bbbxx' where id = 1; -- error
> ERROR: no generation expression found for column number 3 of table
> "foo"

Yes I can see the problem after adding a generated column and dropping
it on an INSERT query.

I have read through the code once.

+ if (relid && attnum && get_attgenerated(relid, attnum))
Better to use OidIsValid here?

+ (walrcv_server_version(wrconn) >= 120000 ? "AND a.attgenerated = ''" : ""),
I think that it is better to always have version-related references
stored as defines.

+CREATE TABLE gtest22a (a int PRIMARY KEY, b int GENERATED ALWAYS AS (a * 2) STORED UNIQUE);
+CREATE TABLE gtest22b (a int, b int GENERATED ALWAYS AS (a * 2) STORED, PRIMARY KEY (a, b));
Some tests for unique constraints with a generated column should be in
place?

It would be nice to have extra tests for forbidden expression types
on generated columns especially SRF, subquery and aggregates/window
functions.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Imai, Yoshikazu 2019-03-20 02:51:10 RE: speeding up planning with partitions
Previous Message Andrey Borodin 2019-03-20 02:48:00 Re: Sparse bit set data structure