Re: [HACKERS] generated columns

On 2019-01-15 08:13, Michael Paquier wrote:
>>> Ah, the volatility checking needs some improvements. I'll address that
>>> in the next patch version.
>>
>> ok
>
> The same problem happens for stored and virtual columns.

This is fixed in v8.

> It would be nice to add a test with composite types, say something
> like:
> =# create type double_int as (a int, b int);
> CREATE TYPE
> =# create table double_tab (a int,
> b double_int GENERATED ALWAYS AS ((a * 2, a * 3)) stored,
> c double_int GENERATED ALWAYS AS ((a * 4, a * 5)) virtual);
> CREATE TABLE
> =# insert into double_tab values (1), (6);
> INSERT 0 2
> =# select * from double_tab ;
> a | b | c
> ---+---------+---------
> 1 | (2,3) | (4,5)
> 6 | (12,18) | (24,30)
> (2 rows)

I added that.

> + bool has_generated_stored;
> + bool has_generated_virtual;
> } TupleConstr;
> Could have been more simple to use a char as representation here.

Seems confusing if both apply at the same time.

> Using NULL as generation expression results in a crash when selecting
> the relation created:
> =# CREATE TABLE gtest_err_1 (a int PRIMARY KEY, b int GENERATED ALWAYS
> AS (NULL));
> CREATE TABLE
> =# select * from gtest_err_1;
> server closed the connection unexpectedly

This is fixed in v8.

> + The view <literal>column_column_usage</literal> identifies all
> generated
> "column_column_usage" is redundant. Could it be possible to come up
> with a better name?

This is specified in the SQL stnadard.

> When testing a bulk INSERT into a table which has a stored generated
> column, memory keeps growing in size linearly, which does not seem
> normal to me.

This was a silly coding error. It's fixed in v8.

> +/*
> + * Thin wrapper around libpq to obtain server version.
> + */
> +static int
> +libpqrcv_server_version(WalReceiverConn *conn)
> This should be introduced in separate patch in my opinion (needed
> afterwards for logirep).

Yes, it could be committed separately.

> What about the catalog representation of attgenerated? Would it merge
> with attidentity & co? Or not?

I think the way it is now seems best. The other options that were
discussed are also plausible, but that the discussions did not reveal
any overwhelming arguments for a a change.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services