summaryrefslogtreecommitdiff
path: root/src/include/commands
diff options
context:
space:
mode:
authorKevin Grittner2013-04-09 18:02:49 +0000
committerKevin Grittner2013-04-09 18:02:49 +0000
commit52e6e33ab495cb2b0e694ee480ba7c6394315053 (patch)
treecf957e2ae91863e97b46f4692f09a339b5cf696f /src/include/commands
parent0bf42a5f3b62cde41cb366d3442585429c6d9c50 (diff)
Create a distinction between a populated matview and a scannable one.
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.
Diffstat (limited to 'src/include/commands')
-rw-r--r--src/include/commands/matview.h2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/include/commands/matview.h b/src/include/commands/matview.h
index b5d52503c0d..09bc384086f 100644
--- a/src/include/commands/matview.h
+++ b/src/include/commands/matview.h
@@ -20,7 +20,7 @@
#include "utils/relcache.h"
-extern void SetRelationIsScannable(Relation relation);
+extern void SetMatViewToPopulated(Relation relation);
extern void ExecRefreshMatView(RefreshMatViewStmt *stmt, const char *queryString,
ParamListInfo params, char *completionTag);