Some conditions on view definition that should be prohibited,
for example,
- SELECT ... FROM func(..., (SELECT ... FROM ...), ..) ...;
- SELECT expr(SELECT ... FROM ...) FROM ...;
were not checked. Also, some error messages and the order of
tests are improved.
When using DELETE or UPDATE, we must use exclusive lock for now
because apply_old_delta(_with_count) could result in wrong results
with concurrent transactions. We would like to improve it in future,
but we prevent it by using the lock for now.
The names of additional columns for aggregate views are derived from column
names specified in the first parameter of create_immv, but when the number
was less than the length of the actual target list, segmentation fault occurred.
Furthermore, when the number of specified columns is more than the target list,
it overrode additional column names and it caused a failure of incremental
maintenance of an aggregate view.
To fix then, check the length of the specified column name list not to access
invalid area, and also prevent from overriding additional column names.
It is intended that a unique index is created only if all primary
keys of tables in FROM clause appear in the target list. For this
purpose, pull_varnos_of_level was used to extract relations in the
FROM clause, but it is incorrect and actually we should use
get_relids_in_jointree.
Due to this bug, an index could be created even even where there
is a pkey attribute from just one of relations in FROM clause.
Previously, IMMV including IMMV in its definition can be created by
create_immv(), but it should not be supported by IMMV because we
cannot maintain it recursively for now. This patch prevents it by raising
an error for such view definition on create_immv().
We usually try to create a unique index on an IMMV for both
performance and constraint reasons. However, we don't need
such index for an aggregate view without GROUP BY because
it has always only one row. Also, we don't need to raise
NOTICE message to suggest to create an index.
This change was mistakenly introduced in cfe9491e6b,
but it should have been a separate commit. In this commit,
a typo and tests are fixed.
In order to re-calculate min/max values for groups where the min
or max value is deleted, we need the view query definition in string
form. However, pg_get_viewdef cannot be used for this purpose because
IMMV's defenition is in pg_ivm_immv but not pg_rewrite. Therefore,
we have to convert query definition in pg_ivm_immv to query
definition string. We can use pg_get_querydef in PG15, but we cannot
in PG14 or earlier, so we use codes in ruleutil.c copied from PG13
or PG14 depending versions.
In PostgreSQL 14 or later, OIDs of aggregate functions are
described in fmrgoids.h, but that in PostgreSQL 13 doesn't
contain aggregate function OIDs. Therefore, we get the OID
by passing the function name and arg type to to_regprocedure().
When a base table is truncated, the view content will be empty if the
view definition query does not contain an aggregate without a GROUP clause.
Therefore, such views can be truncated.
Aggregate views without a GROUP clause always have one row. Therefore,
if a base table is truncated, the view will not be empty and will contain
a row with NULL value (or 0 for count()). So, in this case, we refresh the
view instead of truncating it.
Built-in count, sum, avg are supported. We have not supported min/max
yet, but will support in future.
When an IMMV with any aggregates are defined, additional columns
are created for each aggregate function. Although such columns are
"hidden" in pgsql-ivm version, they are always visible for users
in the extension version.
refresh_immv(immv_name, with_data) is a function to refresh IMMV like
REFRESH MATERIALIZED VIEW command. It has two argument.
immv_name is incrementally maintainable materialized view's name, and
with_data is an option that is corresponding to the WITH [NO] DATA option.
When with_data is set false, the IMMV gets unpopulated.
One of differences between IMMVs unpopulated by this function and
normal materialized views unpopulated by REFRESH ... WITH NO DATA
is that such IMMVs can be referenced by SELECT but return no rows,
while unpopulated materialized views are not scanable.
The behaviour may be changed in future to raise an error when unpopulated
an IMMV is scanned.
