public inbox for [email protected]
help / color / mirror / Atom feedRe: Schema variables - new implementation for Postgres 15
3+ messages / 3 participants
[nested] [flat]
* Re: Schema variables - new implementation for Postgres 15
@ 2023-11-22 06:19 Julien Rouhaud <[email protected]>
2023-11-26 18:19 ` Re: Schema variables - new implementation for Postgres 15 Pavel Stehule <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Julien Rouhaud @ 2023-11-22 06:19 UTC (permalink / raw)
To: Pavel Stehule <[email protected]>; +Cc: Dmitry Dolgov <[email protected]>; Peter Eisentraut <[email protected]>; Sergey Shinderuk <[email protected]>; Tomas Vondra <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]
Hi,
On Tue, Oct 17, 2023 at 08:52:13AM +0200, Pavel Stehule wrote:
>
> When I thought about global temporary tables, I got one maybe interesting
> idea. The one significant problem of global temporary tables is place for
> storing info about size or column statistics.
>
> I think so these data can be stored simply in session variables. Any global
> temporary table can get assigned one session variable, that can hold these
> data.
I don't know how realistic this would be. For instance it will require to
properly link the global temporary table life cycle with the session variable
and I'm afraid it would require to add some hacks to make it work as needed.
But this still raises the question of whether this feature could be used
internally for the need of another feature. If we think it's likely, should we
try to act right now and reserve the "pg_" prefix for internal use rather than
do that a few years down the line and probably break some user code as it was
done recently for the role names?
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Schema variables - new implementation for Postgres 15
2023-11-22 06:19 Re: Schema variables - new implementation for Postgres 15 Julien Rouhaud <[email protected]>
@ 2023-11-26 18:19 ` Pavel Stehule <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Pavel Stehule @ 2023-11-26 18:19 UTC (permalink / raw)
To: Julien Rouhaud <[email protected]>; +Cc: Dmitry Dolgov <[email protected]>; Peter Eisentraut <[email protected]>; Sergey Shinderuk <[email protected]>; Tomas Vondra <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]
Hi
st 22. 11. 2023 v 7:20 odesÃlatel Julien Rouhaud <[email protected]>
napsal:
> Hi,
>
> On Tue, Oct 17, 2023 at 08:52:13AM +0200, Pavel Stehule wrote:
> >
> > When I thought about global temporary tables, I got one maybe interesting
> > idea. The one significant problem of global temporary tables is place for
> > storing info about size or column statistics.
> >
> > I think so these data can be stored simply in session variables. Any
> global
> > temporary table can get assigned one session variable, that can hold
> these
> > data.
>
> I don't know how realistic this would be. For instance it will require to
> properly link the global temporary table life cycle with the session
> variable
> and I'm afraid it would require to add some hacks to make it work as
> needed.
>
> But this still raises the question of whether this feature could be used
> internally for the need of another feature. If we think it's likely,
> should we
> try to act right now and reserve the "pg_" prefix for internal use rather
> than
> do that a few years down the line and probably break some user code as it
> was
> done recently for the role names?
>
I don't think it is necessary. Session variables (in this design) are
joined with schemas. If we use some session variables for system purposes,
we can use some dedicated schema. But when I think about it in detail,
probably my own dedicated storage (hash table in session memory) can be
much better than session variables. What can be shared (maybe) is probably
sinval message processing.
^ permalink raw reply [nested|flat] 3+ messages in thread
* [PATCH v39 5/8] Add Incremental View Maintenance support to psql
@ 2026-05-29 09:05 Yugo Nagata <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Yugo Nagata @ 2026-05-29 09:05 UTC (permalink / raw)
Add tab completion and meta-command output for IVM.
---
src/bin/psql/describe.c | 32 +++++++++++++++++++++++++++++++-
src/bin/psql/tab-complete.in.c | 30 ++++++++++++++++++------------
2 files changed, 49 insertions(+), 13 deletions(-)
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index fef86b4cca3..5b7bf626c32 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -1580,6 +1580,7 @@ describeOneTableDetails(const char *schemaname,
char relpersistence;
char relreplident;
char *relam;
+ bool isivm;
} tableinfo;
bool show_column_details = false;
@@ -1594,7 +1595,26 @@ describeOneTableDetails(const char *schemaname,
/* Get general table info */
printfPQExpBuffer(&buf, "/* %s */\n",
_("Get general information about one relation"));
- if (pset.sversion >= 120000)
+ if (pset.sversion >= 200000)
+ {
+ printfPQExpBuffer(&buf,
+ "SELECT c.relchecks, c.relkind, c.relhasindex, c.relhasrules, "
+ "c.relhastriggers, c.relrowsecurity, c.relforcerowsecurity, "
+ "false AS relhasoids, c.relispartition, %s, c.reltablespace, "
+ "CASE WHEN c.reloftype = 0 THEN '' ELSE c.reloftype::pg_catalog.regtype::pg_catalog.text END, "
+ "c.relpersistence, c.relreplident, am.amname, "
+ "c.relisivm\n"
+ "FROM pg_catalog.pg_class c\n "
+ "LEFT JOIN pg_catalog.pg_class tc ON (c.reltoastrelid = tc.oid)\n"
+ "LEFT JOIN pg_catalog.pg_am am ON (c.relam = am.oid)\n"
+ "WHERE c.oid = '%s';",
+ (verbose ?
+ "pg_catalog.array_to_string(c.reloptions || "
+ "array(select 'toast.' || x from pg_catalog.unnest(tc.reloptions) x), ', ')\n"
+ : "''"),
+ oid);
+ }
+ else if (pset.sversion >= 120000)
{
appendPQExpBuffer(&buf,
"SELECT c.relchecks, c.relkind, c.relhasindex, c.relhasrules, "
@@ -1662,6 +1682,10 @@ describeOneTableDetails(const char *schemaname,
NULL : pg_strdup(PQgetvalue(res, 0, 14));
else
tableinfo.relam = NULL;
+ if (pset.sversion >= 200000)
+ tableinfo.isivm = strcmp(PQgetvalue(res, 0, 15), "t") == 0;
+ else
+ tableinfo.isivm = false;
PQclear(res);
res = NULL;
@@ -3670,6 +3694,12 @@ describeOneTableDetails(const char *schemaname,
printfPQExpBuffer(&buf, _("Access method: %s"), tableinfo.relam);
printTableAddFooter(&cont, buf.data);
}
+
+ /* Incremental view maintance info */
+ if (verbose && tableinfo.relkind == RELKIND_MATVIEW && tableinfo.isivm)
+ {
+ printTableAddFooter(&cont, _("Incremental view maintenance: yes"));
+ }
}
/* reloptions, if verbose */
diff --git a/src/bin/psql/tab-complete.in.c b/src/bin/psql/tab-complete.in.c
index e4bc2c93145..6dfad8a8102 100644
--- a/src/bin/psql/tab-complete.in.c
+++ b/src/bin/psql/tab-complete.in.c
@@ -1320,6 +1320,7 @@ static const pgsql_thing_t words_after_create[] = {
{"FOREIGN TABLE", NULL, NULL, NULL},
{"FUNCTION", NULL, NULL, Query_for_list_of_functions},
{"GROUP", Query_for_list_of_roles},
+ {"INCREMENTAL MATERIALIZED VIEW", NULL, NULL, &Query_for_list_of_matviews, NULL, THING_NO_DROP | THING_NO_ALTER},
{"INDEX", NULL, NULL, &Query_for_list_of_indexes},
{"LANGUAGE", Query_for_list_of_languages},
{"LARGE OBJECT", NULL, NULL, NULL, NULL, THING_NO_CREATE | THING_NO_DROP},
@@ -4242,28 +4243,33 @@ match_previous_words(int pattern_id,
COMPLETE_WITH("SELECT");
/* CREATE MATERIALIZED VIEW */
- else if (Matches("CREATE", "MATERIALIZED"))
+ else if (Matches("CREATE", "MATERIALIZED") ||
+ Matches("CREATE", "INCREMENTAL", "MATERIALIZED"))
COMPLETE_WITH("VIEW");
- /* Complete CREATE MATERIALIZED VIEW <name> with AS or USING */
- else if (Matches("CREATE", "MATERIALIZED", "VIEW", MatchAny))
- COMPLETE_WITH("AS", "USING");
+ /* Complete CREATE [INCREMENTAL] MATERIALIZED VIEW <name> with AS or USING */
+ else if (Matches("CREATE", "MATERIALIZED", "VIEW", MatchAny) ||
+ Matches("CREATE", "INCREMENTAL", "MATERIALIZED", "VIEW", MatchAny))
+ COMPLETE_WITH("AS", "USING");
/*
- * Complete CREATE MATERIALIZED VIEW <name> USING with list of access
- * methods
+ * Complete CREATE [INCREMENTAL] MATERIALIZED VIEW <name> USING with list
+ * of access methods
*/
- else if (Matches("CREATE", "MATERIALIZED", "VIEW", MatchAny, "USING"))
+ else if (Matches("CREATE", "MATERIALIZED", "VIEW", MatchAny, "USING") ||
+ Matches("CREATE", "INCREMENTAL", "MATERIALIZED", "VIEW", MatchAny, "USING"))
COMPLETE_WITH_QUERY(Query_for_list_of_table_access_methods);
- /* Complete CREATE MATERIALIZED VIEW <name> USING <access method> with AS */
- else if (Matches("CREATE", "MATERIALIZED", "VIEW", MatchAny, "USING", MatchAny))
+ /* Complete CREATE [INCREMENTAL] MATERIALIZED VIEW <name> USING <am> with AS */
+ else if (Matches("CREATE", "MATERIALIZED", "VIEW", MatchAny, "USING", MatchAny) ||
+ Matches("CREATE", "INCREMENTAL", "MATERIALIZED", "VIEW", MatchAny, "USING", MatchAny))
COMPLETE_WITH("AS");
-
/*
- * Complete CREATE MATERIALIZED VIEW <name> [USING <access method> ] AS
+ * Complete CREATE [INCREMENTAL] MATERIALIZED VIEW <name> [USING <am>] AS
* with "SELECT"
*/
else if (Matches("CREATE", "MATERIALIZED", "VIEW", MatchAny, "AS") ||
- Matches("CREATE", "MATERIALIZED", "VIEW", MatchAny, "USING", MatchAny, "AS"))
+ Matches("CREATE", "MATERIALIZED", "VIEW", MatchAny, "USING", MatchAny, "AS") ||
+ Matches("CREATE", "INCREMENTAL", "MATERIALIZED", "VIEW", MatchAny, "AS") ||
+ Matches("CREATE", "INCREMENTAL", "MATERIALIZED", "VIEW", MatchAny, "USING", MatchAny, "AS"))
COMPLETE_WITH("SELECT");
/* CREATE EVENT TRIGGER */
--
2.43.0
--Multipart=_Fri__3_Jul_2026_19_11_16_+0900_CskxSIu_iGcDMEyM
Content-Type: text/x-diff;
name="v39-0004-Add-Incremental-View-Maintenance-support-to-pg_d.patch"
Content-Disposition: attachment;
filename="v39-0004-Add-Incremental-View-Maintenance-support-to-pg_d.patch"
Content-Transfer-Encoding: 7bit
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-05-29 09:05 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-11-22 06:19 Re: Schema variables - new implementation for Postgres 15 Julien Rouhaud <[email protected]>
2023-11-26 18:19 ` Pavel Stehule <[email protected]>
2026-05-29 09:05 [PATCH v39 5/8] Add Incremental View Maintenance support to psql Yugo Nagata <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox