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