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
