pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18178: New Restriction on "ON SELECT" rules on tables
8+ messages / 5 participants
[nested] [flat]
Commits from this thread:
2023-11-03 95a610b097 1f7d7f102d 3f9fe9b76f 111364ec20 9d4ea0bb3f 58d3283b67 f53f83b33e Doc: update CREATE RULE ref page's hoary discussion of views.
* BUG #18178: New Restriction on "ON SELECT" rules on tables
@ 2023-11-01 23:25 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 3 replies; 8+ messages in thread
From: PG Bug reporting form @ 2023-11-01 23:25 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: joshua.uyehara@gmail.com
The following bug has been logged on the website:
Bug reference: 18178
Logged by: Joshua Uyehara
Email address: joshua.uyehara@gmail.com
PostgreSQL version: 16.0
Operating system: Windows Server 2022
Description:
Hello,
Apologies if this is not the right place to report this, but it is either a
'bug' in the documentation, or (I'm hoping) a breaking change that could be
reverted.
The documentation for rules specifically states that "ON SELECT" rules can
be created on tables (and I have functionality/use cases that rely on that)
behavior, but pg16 breaks that.
In investigating the issue I did find what is likely the related release
note for 16 "Remove the ability to create views manually with ON SELECT
rules (Tom Lane)", but couldn't find any related discussion of the
rationale, suggested workarounds, or whether anyone else has yet run into
the same class of issues (possible given the recency of the release).
The issue is, basically, that there are broad classes of database
abstraction middleware that are configured via database introspection at
runtime and do not understand or implement the concept of updateable views
and foreign tables. The easiest workaround for that limitation in postgres
has always been to create a local table stand-in with all operations
rerouted to the foreign table via rules.
If I need to report this somewhere else, or send to one of the mailing
lists, please let me know.
Regards,
Josh
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18178: New Restriction on "ON SELECT" rules on tables
@ 2023-11-02 09:44 Daniel Gustafsson <daniel@yesql.se>
parent: PG Bug reporting form <noreply@postgresql.org>
2 siblings, 0 replies; 8+ messages in thread
From: Daniel Gustafsson @ 2023-11-02 09:44 UTC (permalink / raw)
To: joshua.uyehara@gmail.com; pgsql-bugs@lists.postgresql.org
> On 2 Nov 2023, at 00:25, PG Bug reporting form <noreply@postgresql.org> wrote:
> In investigating the issue I did find what is likely the related release
> note for 16 "Remove the ability to create views manually with ON SELECT
> rules (Tom Lane)", but couldn't find any related discussion of the
> rationale, suggested workarounds, or whether anyone else has yet run into
> the same class of issues (possible given the recency of the release).
The discussion which led to this change can be found in this thread:
https://www.postgresql.org/message-id/flat/CALDaNm2yXz%2BzOtv7y5zBd5WKT8O0Ld3YxikuU3dcyCvxF7gypA%40m...
While it might not contain any workarounds, it might at least share insights
into the rationale for it.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18178: New Restriction on "ON SELECT" rules on tables
@ 2023-11-02 10:40 Laurenz Albe <laurenz.albe@cybertec.at>
parent: PG Bug reporting form <noreply@postgresql.org>
2 siblings, 0 replies; 8+ messages in thread
From: Laurenz Albe @ 2023-11-02 10:40 UTC (permalink / raw)
To: joshua.uyehara@gmail.com; pgsql-bugs@lists.postgresql.org
On Wed, 2023-11-01 at 23:25 +0000, PG Bug reporting form wrote:
> PostgreSQL version: 16.0
> Operating system: Windows Server 2022
>
> Apologies if this is not the right place to report this, but it is either a
> 'bug' in the documentation, or (I'm hoping) a breaking change that could be
> reverted.
>
> The documentation for rules specifically states that "ON SELECT" rules can
> be created on tables (and I have functionality/use cases that rely on that)
> behavior, but pg16 breaks that.
Where does it say that? That would be a documentation bug.
> In investigating the issue I did find what is likely the related release
> note for 16 "Remove the ability to create views manually with ON SELECT
> rules (Tom Lane)", but couldn't find any related discussion of the
> rationale, suggested workarounds, or whether anyone else has yet run into
> the same class of issues (possible given the recency of the release).
The relevant commit is here:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b23cd185fd5410e5204683933f848d4583e34...
and it links to this discussion thread:
https://www.postgresql.org/message-id/flat/CALDaNm2yXz%2BzOtv7y5zBd5WKT8O0Ld3YxikuU3dcyCvxF7gypA%40m...
Basically, the behavior was considered a wart, and it caused problems,
so it was decided to get rid of it.
> The issue is, basically, that there are broad classes of database
> abstraction middleware that are configured via database introspection at
> runtime and do not understand or implement the concept of updateable views
> and foreign tables. The easiest workaround for that limitation in postgres
> has always been to create a local table stand-in with all operations
> rerouted to the foreign table via rules.
So these "broad classes of database abstraction middleware" are smart
enough to tell that a foreign table is not a table, but too dumb to
recognize a table that has been converted to a view.
What keeps you from creating a view instead of creating a table and
then turning it into a view? Can the "broad classes" distinguish between
these two things? How? It cannot be pg_class.relkind, because
that is changed when you create an ON SELECT rule called _RETURN.
Perhaps pg_class.relfilenode?
> If I need to report this somewhere else, or send to one of the mailing
> lists, please let me know.
You have been relying on a hack to work around a deficiency in the "broad
classes". I can't speak for PostgreSQL, but I see little chance for this
change to be reverted.
I'd say that the correct thing to do would be to ask the "broad classes"
to enhance their code so that they work properly with foreign tables.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18178: New Restriction on "ON SELECT" rules on tables
@ 2023-11-02 14:20 Tom Lane <tgl@sss.pgh.pa.us>
parent: PG Bug reporting form <noreply@postgresql.org>
2 siblings, 1 reply; 8+ messages in thread
From: Tom Lane @ 2023-11-02 14:20 UTC (permalink / raw)
To: joshua.uyehara@gmail.com; +Cc: pgsql-bugs@lists.postgresql.org
PG Bug reporting form <noreply@postgresql.org> writes:
> The documentation for rules specifically states that "ON SELECT" rules can
> be created on tables (and I have functionality/use cases that rely on that)
> behavior, but pg16 breaks that.
If the documentation still says that, it needs to be updated.
What are you looking at precisely?
> The issue is, basically, that there are broad classes of database
> abstraction middleware that are configured via database introspection at
> runtime and do not understand or implement the concept of updateable views
> and foreign tables. The easiest workaround for that limitation in postgres
> has always been to create a local table stand-in with all operations
> rerouted to the foreign table via rules.
TBH, I don't believe that argument for a second. Pre-v16, what
happened when you added an ON SELECT rule to a table is that *the
table got changed into a view* (which is what caused the bugs
mentioned in the thread Daniel pointed you to). There is no
difference between the subsequent catalog state and what you would
have if you'd just created it as a view in the first place. So
do that and then add whatever non-SELECT rules you need, and you
should be in the same place as before (and your code will still
work with pre-v16 releases, too).
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18178: New Restriction on "ON SELECT" rules on tables
@ 2023-11-03 10:44 Joshua Uyehara <joshua.uyehara@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 8+ messages in thread
From: Joshua Uyehara @ 2023-11-03 10:44 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-bugs@lists.postgresql.org
Thank you (and Laurenz and Daniel) for the collectively comprehensive
response and background information.
Makes sense that supporting workaround hacks is not worthwhile given it's
actually causing a problem. I'm now actually more curious why it even
worked given the explanations and linked discussions.
As far as the documentation error, on closer review, Part V, 41.2 ("Views
and the Rules system") was updated to reflect the change, but the Reference
entry for Create Rule in Part VI was not:
Presently, ON SELECT rules must be unconditional INSTEAD rules and must
> have actions that consist of a single SELECT command. Thus, an ON SELECT rule
> effectively turns the table into a view, whose visible contents are the
> rows returned by the rule's SELECT command rather than whatever had been
> stored in the table (if anything). It is considered better style to write a CREATE
> VIEW command than to create a real table and define an ON SELECT rule for
> it.
Regards,
Josh Uyehara
On Thu, Nov 2, 2023 at 4:20 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> PG Bug reporting form <noreply@postgresql.org> writes:
> > The documentation for rules specifically states that "ON SELECT" rules
> can
> > be created on tables (and I have functionality/use cases that rely on
> that)
> > behavior, but pg16 breaks that.
>
> If the documentation still says that, it needs to be updated.
> What are you looking at precisely?
>
> > The issue is, basically, that there are broad classes of database
> > abstraction middleware that are configured via database introspection at
> > runtime and do not understand or implement the concept of updateable
> views
> > and foreign tables. The easiest workaround for that limitation in
> postgres
> > has always been to create a local table stand-in with all operations
> > rerouted to the foreign table via rules.
>
> TBH, I don't believe that argument for a second. Pre-v16, what
> happened when you added an ON SELECT rule to a table is that *the
> table got changed into a view* (which is what caused the bugs
> mentioned in the thread Daniel pointed you to). There is no
> difference between the subsequent catalog state and what you would
> have if you'd just created it as a view in the first place. So
> do that and then add whatever non-SELECT rules you need, and you
> should be in the same place as before (and your code will still
> work with pre-v16 releases, too).
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18178: New Restriction on "ON SELECT" rules on tables
@ 2023-11-03 15:21 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Joshua Uyehara <joshua.uyehara@gmail.com>
1 sibling, 1 reply; 8+ messages in thread
From: Laurenz Albe @ 2023-11-03 15:21 UTC (permalink / raw)
To: Joshua Uyehara <joshua.uyehara@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-bugs@lists.postgresql.org
On Fri, 2023-11-03 at 00:44 -1000, Joshua Uyehara wrote:
> As far as the documentation error, on closer review, Part V, 41.2 ("Views and the Rules system")
> was updated to reflect the change, but the Reference entry for Create Rule in Part VI was not:
>
> > Presently, ON SELECT rules must be unconditional INSTEAD rules and must have actions that
> > consist of a single SELECT command. Thus, an ON SELECT rule effectively turns the table into
> > a view, whose visible contents are the rows returned by the rule's SELECT command rather than
> > whatever had been stored in the table (if anything). It is considered better style to write a
> > CREATE VIEW command than to create a real table and define an ON SELECT rule for it.
Yes, that paragraph has to go.
But I wonder if it would not be better to completely remove ON SELECT from the CREATE RULE
command. Attached is a patch that does that.
The documentation part of this patch should be backpatched to v16, but the rest is
HEAD only.
Yours,
Laurenz Albe
Attachments:
0001-Forbid-explicitly-creating-ON-SELECT-rules.patch (text/x-patch, 9.0K) download
From 704c9dc00a26007ef4a091d739540ad39af8af33 Mon Sep 17 00:00:00 2001
From: Laurenz Albe <laurenz.albe@cybertec.at>
Date: Fri, 3 Nov 2023 16:18:47 +0100
Subject: [PATCH] Forbid explicitly creating ON SELECT rules
Commit b23cd185fd disallowed ON SELECT rules to be created on tables,
but the documentation of CREATE RULE was not modified accordingly.
Since it is no longer possible to explicitly create ON SELECT rules,
we had better remove the option from the grammar and from the
documentation of CREATE RULE.
The documentation chapter about rules still discusses ON SELECT rules,
since they are used in views, but there is now a sentence to make
clear that you cannot explicitly create such rules any more.
Adapt psql tab completion accordingly.
Report: Joshua Uyehara
Author: Laurenz Albe
Discussion: https://postgr.es/m/18178-05534d7064044d2d%40postgresql.org
---
doc/src/sgml/ref/create_rule.sgml | 33 +++++++++++------------------
doc/src/sgml/rules.sgml | 4 ++--
src/backend/parser/gram.y | 3 +--
src/bin/psql/tab-complete.c | 10 ++++-----
src/test/regress/expected/rules.out | 22 -------------------
src/test/regress/sql/rules.sql | 21 ------------------
6 files changed, 20 insertions(+), 73 deletions(-)
diff --git a/doc/src/sgml/ref/create_rule.sgml b/doc/src/sgml/ref/create_rule.sgml
index dbf4c93784..eea3781a9b 100644
--- a/doc/src/sgml/ref/create_rule.sgml
+++ b/doc/src/sgml/ref/create_rule.sgml
@@ -27,7 +27,7 @@ CREATE [ OR REPLACE ] RULE <replaceable class="parameter">name</replaceable> AS
<phrase>where <replaceable class="parameter">event</replaceable> can be one of:</phrase>
- SELECT | INSERT | UPDATE | DELETE
+ INSERT | UPDATE | DELETE
</synopsis>
</refsynopsisdiv>
@@ -59,15 +59,9 @@ CREATE [ OR REPLACE ] RULE <replaceable class="parameter">name</replaceable> AS
</para>
<para>
- Presently, <literal>ON SELECT</literal> rules must be unconditional
- <literal>INSTEAD</literal> rules and must have actions that consist
- of a single <command>SELECT</command> command. Thus, an
- <literal>ON SELECT</literal> rule effectively turns the table into
- a view, whose visible contents are the rows returned by the rule's
- <command>SELECT</command> command rather than whatever had been
- stored in the table (if anything). It is considered better style
- to write a <command>CREATE VIEW</command> command than to create a
- real table and define an <literal>ON SELECT</literal> rule for it.
+ There are also <literal>ON SELECT</literal> rules, but you can no
+ longer create them explicitly. An <literal>ON SELECT</literal> rule
+ is created implicitly by <command>CREATE VIEW</command>.
</para>
<para>
@@ -134,7 +128,7 @@ CREATE [ OR REPLACE ] RULE <replaceable class="parameter">name</replaceable> AS
<term><replaceable class="parameter">event</replaceable></term>
<listitem>
<para>
- The event is one of <literal>SELECT</literal>,
+ The event is one of
<literal>INSERT</literal>, <literal>UPDATE</literal>, or
<literal>DELETE</literal>. Note that an
<command>INSERT</command> containing an <literal>ON
@@ -244,24 +238,21 @@ CREATE [ OR REPLACE ] RULE <replaceable class="parameter">name</replaceable> AS
<para>
It is very important to take care to avoid circular rules. For
- example, though each of the following two rule definitions are
+ example, though the following rule definition is
accepted by <productname>PostgreSQL</productname>, the
- <command>SELECT</command> command would cause
+ <command>INSERT</command> command would cause
<productname>PostgreSQL</productname> to report an error because
of recursive expansion of a rule:
<programlisting>
-CREATE RULE "_RETURN" AS
- ON SELECT TO t1
- DO INSTEAD
- SELECT * FROM t2;
+CREATE TABLE t1 (i integer);
-CREATE RULE "_RETURN" AS
- ON SELECT TO t2
+CREATE RULE recurse AS
+ ON INSERT TO t1
DO INSTEAD
- SELECT * FROM t1;
+ INSERT INTO t1 VALUES (NEW.i + 1);
-SELECT * FROM t1;
+INSERT INTO t1 (i) VALUES (1);
</programlisting>
</para>
diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index d229b94d39..c9464f6309 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -297,8 +297,8 @@ CREATE RULE "_RETURN" AS ON SELECT TO myview DO INSTEAD
SELECT * FROM mytab;
</programlisting>
- although you can't actually write that, because tables are not
- allowed to have <literal>ON SELECT</literal> rules.
+ although you can't actually write that, because you cannot explicitly
+ create <literal>ON SELECT</literal> rules.
</para>
<para>
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index c224df4ecc..c6bee8b2c7 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -10815,8 +10815,7 @@ RuleActionStmtOrEmpty:
| /*EMPTY*/ { $$ = NULL; }
;
-event: SELECT { $$ = CMD_SELECT; }
- | UPDATE { $$ = CMD_UPDATE; }
+event: UPDATE { $$ = CMD_UPDATE; }
| DELETE_P { $$ = CMD_DELETE; }
| INSERT { $$ = CMD_INSERT; }
;
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index 93742fc6ac..3bdc8cc250 100644
--- a/src/bin/psql/tab-complete.c
+++ b/src/bin/psql/tab-complete.c
@@ -3153,16 +3153,16 @@ psql_completion(const char *text, int start, int end)
/*
* Complete "CREATE [ OR REPLACE ] RULE <sth> AS ON" with
- * SELECT|UPDATE|INSERT|DELETE
+ * UPDATE|INSERT|DELETE
*/
else if (Matches("CREATE", "RULE", MatchAny, "AS", "ON") ||
Matches("CREATE", "OR", "REPLACE", "RULE", MatchAny, "AS", "ON"))
- COMPLETE_WITH("SELECT", "UPDATE", "INSERT", "DELETE");
- /* Complete "AS ON SELECT|UPDATE|INSERT|DELETE" with a "TO" */
- else if (TailMatches("AS", "ON", "SELECT|UPDATE|INSERT|DELETE"))
+ COMPLETE_WITH("UPDATE", "INSERT", "DELETE");
+ /* Complete "AS ON UPDATE|INSERT|DELETE" with a "TO" */
+ else if (TailMatches("AS", "ON", "UPDATE|INSERT|DELETE"))
COMPLETE_WITH("TO");
/* Complete "AS ON <sth> TO" with a table name */
- else if (TailMatches("AS", "ON", "SELECT|UPDATE|INSERT|DELETE", "TO"))
+ else if (TailMatches("AS", "ON", "UPDATE|INSERT|DELETE", "TO"))
COMPLETE_WITH_SCHEMA_QUERY(Query_for_list_of_tables);
/* CREATE SCHEMA [ <name> ] [ AUTHORIZATION ] */
diff --git a/src/test/regress/expected/rules.out b/src/test/regress/expected/rules.out
index 2c60400ade..fca63b941f 100644
--- a/src/test/regress/expected/rules.out
+++ b/src/test/regress/expected/rules.out
@@ -2743,28 +2743,6 @@ ERROR: cannot drop rule _RETURN on view rules_fooview because view rules_foovie
HINT: You can drop view rules_fooview instead.
drop view rules_fooview;
--
--- We used to allow converting a table to a view by creating a "_RETURN"
--- rule for it, but no more.
---
-create table rules_fooview (x int, y text);
-create rule "_RETURN" as on select to rules_fooview do instead
- select 1 as x, 'aaa'::text as y;
-ERROR: relation "rules_fooview" cannot have ON SELECT rules
-DETAIL: This operation is not supported for tables.
-drop table rules_fooview;
--- likewise, converting a partitioned table or partition to view is not allowed
-create table rules_fooview (x int, y text) partition by list (x);
-create rule "_RETURN" as on select to rules_fooview do instead
- select 1 as x, 'aaa'::text as y;
-ERROR: relation "rules_fooview" cannot have ON SELECT rules
-DETAIL: This operation is not supported for partitioned tables.
-create table rules_fooview_part partition of rules_fooview for values in (1);
-create rule "_RETURN" as on select to rules_fooview_part do instead
- select 1 as x, 'aaa'::text as y;
-ERROR: relation "rules_fooview_part" cannot have ON SELECT rules
-DETAIL: This operation is not supported for tables.
-drop table rules_fooview;
---
-- check for planner problems with complex inherited UPDATES
--
create table id (id serial primary key, name text);
diff --git a/src/test/regress/sql/rules.sql b/src/test/regress/sql/rules.sql
index 8b7e255dcd..e3f8e10c33 100644
--- a/src/test/regress/sql/rules.sql
+++ b/src/test/regress/sql/rules.sql
@@ -883,27 +883,6 @@ create view rules_fooview as select 'rules_foo'::text;
drop rule "_RETURN" on rules_fooview;
drop view rules_fooview;
---
--- We used to allow converting a table to a view by creating a "_RETURN"
--- rule for it, but no more.
---
-
-create table rules_fooview (x int, y text);
-create rule "_RETURN" as on select to rules_fooview do instead
- select 1 as x, 'aaa'::text as y;
-drop table rules_fooview;
-
--- likewise, converting a partitioned table or partition to view is not allowed
-create table rules_fooview (x int, y text) partition by list (x);
-create rule "_RETURN" as on select to rules_fooview do instead
- select 1 as x, 'aaa'::text as y;
-
-create table rules_fooview_part partition of rules_fooview for values in (1);
-create rule "_RETURN" as on select to rules_fooview_part do instead
- select 1 as x, 'aaa'::text as y;
-
-drop table rules_fooview;
-
--
-- check for planner problems with complex inherited UPDATES
--
--
2.41.0
* Re: BUG #18178: New Restriction on "ON SELECT" rules on tables
@ 2023-11-03 15:50 Tom Lane <tgl@sss.pgh.pa.us>
parent: Joshua Uyehara <joshua.uyehara@gmail.com>
1 sibling, 0 replies; 8+ messages in thread
From: Tom Lane @ 2023-11-03 15:50 UTC (permalink / raw)
To: Joshua Uyehara <joshua.uyehara@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org
Joshua Uyehara <joshua.uyehara@gmail.com> writes:
> As far as the documentation error, on closer review, Part V, 41.2 ("Views
> and the Rules system") was updated to reflect the change, but the Reference
> entry for Create Rule in Part VI was not:
Hah! That text is so old that it still refers to the pre-7.1 behavior
where a view really was a plain table (in the sense of having some
underlying storage). I pushed an update. Thanks for noting that.
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18178: New Restriction on "ON SELECT" rules on tables
@ 2023-11-03 15:53 Tom Lane <tgl@sss.pgh.pa.us>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 0 replies; 8+ messages in thread
From: Tom Lane @ 2023-11-03 15:53 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Joshua Uyehara <joshua.uyehara@gmail.com>; pgsql-bugs@lists.postgresql.org
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> But I wonder if it would not be better to completely remove ON SELECT from the CREATE RULE
> command. Attached is a patch that does that.
I don't think this is a great idea. There are perhaps still pg_dump
scripts out there that use CREATE OR REPLACE RULE "_RETURN" to adjust
view definitions.
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2023-11-03 15:53 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-11-01 23:25 BUG #18178: New Restriction on "ON SELECT" rules on tables PG Bug reporting form <noreply@postgresql.org>
2023-11-02 09:44 ` Daniel Gustafsson <daniel@yesql.se>
2023-11-02 10:40 ` Laurenz Albe <laurenz.albe@cybertec.at>
2023-11-02 14:20 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-11-03 10:44 ` Joshua Uyehara <joshua.uyehara@gmail.com>
2023-11-03 15:21 ` Laurenz Albe <laurenz.albe@cybertec.at>
2023-11-03 15:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-11-03 15:50 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox