database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-25 01:02:05 +03:00
Code Activity

Create a distinction between a populated matview and a scannable one.

Browse Source 
The intent was that being populated would, long term, be just one
of the conditions which could affect whether a matview was
scannable; being populated should be necessary but not always
sufficient to scan the relation.  Since only CREATE and REFRESH
currently determine the scannability, names and comments
accidentally conflated these concepts, leading to confusion.

Also add missing locking for the SQL function which allows a
test for scannability, and fix a modularity violatiion.

Per complaints from Tom Lane, although its not clear that these
will satisfy his concerns.  Hopefully this will at least better
frame the discussion.
This commit is contained in:
Kevin Grittner
2013-04-09 13:02:49 -05:00
parent 0bf42a5f3b
commit 52e6e33ab4
10 changed files with 81 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
src/backend/utils/adt/dbsize.c
View File

@ -840,7 +840,8 @@ pg_relation_filepath(PG_FUNCTION_ARGS)
* Indicate whether a relation is scannable.
*
* Currently, this is always true except for a materialized view which has not
* been populated.
* been populated. It is expected that other conditions for allowing a
* materialized view to be scanned will be added in later releases.
*/
Datum
pg_relation_is_scannable(PG_FUNCTION_ARGS)
@ -850,9 +851,13 @@ pg_relation_is_scannable(PG_FUNCTION_ARGS)
bool result;
relid = PG_GETARG_OID(0);
relation = RelationIdGetRelation(relid);
result = relation->rd_isscannable;
RelationClose(relation);
relation = try_relation_open(relid, AccessShareLock);
if (relation == NULL)
PG_RETURN_BOOL(false);
result = RelationIsScannable(relation);
relation_close(relation, AccessShareLock);
PG_RETURN_BOOL(result);
}