Build errors/warnings against PostgreSQL 16 are fixed.
Also, adapted to the change of codes, including:
- Get rid of the "new" and "old" entries in a view's rangetable.
(Although, removed codes were dead codes because pg_ivm doesn't
have any rules in pg_rewrite.)
- Rework query relation permission checking
- Require empty Bitmapsets to be represented as NULL
- Fix some compiler warnings
Currently, types that does not have an equality operator cannot
be used in the target list of the view definition, because all
of target list entries are used for comparison to identify rows
to be updated or deleted in the view. Previously, an error is
raised at the time such view is incrementally maintained, this
is fixed to check that at the view creation time.
This restriction may be relaxed in future after we can use an
index to identify rows in the view.
Issue #61
Add EXISTS clause support in IVM
Correlated subqueries using EXISTS in WHERE clause are supported.
An EXISTS subquery in WHERE clause is rewritten to LATERAL subquery
in FROM clause, and IVM' process can handle this like as a normal join.
Also, hidden columns "ivm_exists_count_X__" are added to check if
EXISTS condition is satisfied. This column stores the count of how many
rows in the subquery are correlated to (joined to) each row of the main
query. When a base table contained in EXISTS clause is modified, this
count value in IMMV is updated, and a row whose count becomes zero
is deleted.
restrictions :
- EXISTS subqueries are allowed only in WHERE clause.
- aggregate functions are not supported together with EXISTS.
- EXISTS subqueries in a subquery are not supported.
- EXISTS condition can use only with AND Expr
Cached plans for recalculating min/max values are built using
pg_ivm_get_viewdef() that returns the view definition query text.
Therefore, if the search_path is changed, the query text is analyzed
again by SPI, and tables or functions in a wrong schema could be
referenced in the plan.
To fix this, we check whether the search_path is still the same
as when we made the cached plan and, if it isn't, we rebuild the
query text.
CVE-2023-23554
Previously, functions names in pg_catalog schema that were used during
view maintenance were not qualified. This is problematic because
functions in other schema could be referenced unintentionally. Moreover,
that could result in privilege escalation that if a nefarious user who
can create a function, arbitrary functions could be executed under IMMV
owner's privilege.
CVE-2023-23554
The view maintenance is performed under the view owner privilege.
If a modified table has a RLS policy, the policy must be applied
to relation for the pre-update-state table and the delta table
that contained inserted or deleted tuples. Previously, the security
quals were set to each ENR in a subquery that represents such
relation. However, the security check on the delta table was not
properly handled, and this caused that rows that must not be
accessed from the view owner could appear in the view contents
when the view was refreshed incrementally during a query containing
multiple types of commands, like a modifying CTE that contains
INSERT and UPDATE, or a MERGE command.
This patch fixes it by setting RLS policy to a subquery that
presents the pre-update-state table and the delta able instead of
to each RLS. Also, this change makes the code more simple and easy
to maintain.
CVE-2023-22847
Simple CTEs which does not contain aggregates or DISTINCT are
now supported similarly to simple sub-queries.
Before a view is maintained, all CTEs are converted to corresponding
subqueries to enable to treat CTEs as same as subqueries. For this
end, codes of the static function inline_cte in the core
(optimizer/plan/subselect.c) was imported.
Prohibit Unreferenced CTE is prohibited.
When a table in a unreferenced CTE is TRUNCATEd, the contents
of the IMMV is not affected so it must not be truncated. For
confirming it at the maintenance time, we have to check if the
modified table used in a CTE is actually referenced. Although
it would possible, we just disallow to create such IMMVs for now
since such unreferenced CTE is useless unless it doesn't contain
modifying commands, that is already prohibited.
It was added by 3de95c09 for consistency with the patch version
proposed for PostgreSQL core, but the called function was not
one we intended. Fortunately, the behavior has not been affected.
Now, I decided to remove this funciton since I come to think it is
confusable.
Also, added some comments on an argument left for the similar
consistency.
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.
Previously, it caused an error due to an ambiguous reference
at the maintenance time because generate_series is used internally.
This is fixed by using an alias name for the internal genearet_series.
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().
Previously, we used an event trigger and executed DELETE command,
but it caused a privilege error when non-superuser dropped a table
even if it is irrelevant to IMMV.
To fix it, we now use object_access_hook and an entry is deleted
via CatalogTupleDelete which doesn't need the superuser privilege.
Issue #25
When multiple tables are updated or the view contains a self-join,
we need to calculate table states that was before it is modified
during incremental view maintenance. For get the pre-update state,
tuples inserted in a command must be removed when the table is scanned.
Previously, we used xmin and cmin system columns for this purpose,
but this way is problematic because after a tuple is frozen, its xmin
no longer has any meaning. Actually, we will get inconsistent view
results after XID wraparound.
Also, we can see similar similar inconsistency when using sub-transaction
because xmin values do not always monotonically increasing by command
executions.
To fix this, we use a snapshot that taken just before the table is
modified for checking tuple visibility in pre-state table instead of
using xmin and cmin system columns. A new function returning boolean,
ivm_visible_in_prestate, is added, and this is called in WHERE clause
of sub-queries to calculate pre-state table. This function check if a
specified tuple in the post-update table is visible or not using the
snapshot and return true if the tuple is visible.
Previously, a query string returned from pg_ivm_get_querydef
did not include column names specified when IMMV was defined
by create_immv. This caused failures in maintenance of MIN/MAX
aggregate views whose columns had alias names.
It is fixed by rewriting the result column name in the parse tree
using the view's tuple descriptor prior to calling pg_get_querydef
for PG15 or higher, or specifying the tuple descriptor to
get_query_def for PG14 or earlier.
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.
Per sub-queries support, a test for join with subquery is added.
In passing, the order of tests are fixed with according to that in pgsql-ivm.
Also, some other tests related to aggregates and sub-queries are added.
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.
- Allow to use qualified name
- Confirm if executed by the owner of the IMMV
- Improve the message when specified relation is not an IMMV
- Create a unique index at refresh with no dat if possible
This is actually required, but we want it behave as same
as the pgsql-ivm version for now.
