pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedsmall patch
16+ messages / 4 participants
[nested] [flat]
* small patch
@ 2021-10-02 01:06 rir <rirans@comcast.net>
0 siblings, 1 reply; 16+ messages in thread
From: rir @ 2021-10-02 01:06 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org
Minor changes to move.sgml and fetch.sgml.
The text 'or empty' is inconsistent by restating what the
synopsis notation has expressed.
The comments on sharing a language feature, while
likely helpful during review, seem verbose compared to
the non-commenting in other similar files.
Thanks again,
Rob
Attachments:
[text/x-diff] empty.patch (1.7K, ../../20211001163938.ifg4ayrsjwd7r6zr@localhost/2-empty.patch)
download | inline diff:
:From a297377ad3b760f10e951cf67ad0cea704214f34 Mon Sep 17 00:00:00 2001
From: rir <rirans@comcast.net>
Date: Wed, 29 Sep 2021 19:06:01 -0400
Subject: [PATCH] "empty or" is unusual and redundant
---
doc/src/sgml/ref/fetch.sgml | 4 ++--
doc/src/sgml/ref/move.sgml | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/src/sgml/ref/fetch.sgml b/doc/src/sgml/ref/fetch.sgml
index ec843f5684..e76b6fc69d 100644
--- a/doc/src/sgml/ref/fetch.sgml
+++ b/doc/src/sgml/ref/fetch.sgml
@@ -25,11 +25,11 @@ PostgreSQL documentation
</refnamediv>
<refsynopsisdiv>
-<!-- Note the "direction" bit is also in ref/move.sgml -->
+
<synopsis>
FETCH [ <replaceable class="parameter">direction</replaceable> [ FROM | IN ] ] <replaceable class="parameter">cursor_name</replaceable>
-<phrase>where <replaceable class="parameter">direction</replaceable> can be empty or one of:</phrase>
+<phrase>where <replaceable class="parameter">direction</replaceable> can one of:</phrase>
NEXT
PRIOR
diff --git a/doc/src/sgml/ref/move.sgml b/doc/src/sgml/ref/move.sgml
index 4c7d1dca39..1ed06e4c9a 100644
--- a/doc/src/sgml/ref/move.sgml
+++ b/doc/src/sgml/ref/move.sgml
@@ -25,11 +25,11 @@ PostgreSQL documentation
</refnamediv>
<refsynopsisdiv>
-<!-- Note the "direction" bit is also in ref/fetch.sgml -->
+
<synopsis>
MOVE [ <replaceable class="parameter">direction</replaceable> [ FROM | IN ] ] <replaceable class="parameter">cursor_name</replaceable>
-<phrase>where <replaceable class="parameter">direction</replaceable> can be empty or one of:</phrase>
+<phrase>where <replaceable class="parameter">direction</replaceable> can one of:</phrase>
NEXT
PRIOR
--
2.20.1
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-04 06:18 Laurenz Albe <laurenz.albe@cybertec.at>
parent: rir <rirans@comcast.net>
0 siblings, 1 reply; 16+ messages in thread
From: Laurenz Albe @ 2021-10-04 06:18 UTC (permalink / raw)
To: rir <rirans@comcast.net>; pgsql-docs@lists.postgresql.org
On Fri, 2021-10-01 at 21:06 -0400, rir wrote:
> Minor changes to move.sgml and fetch.sgml.
>
> The text 'or empty' is inconsistent by restating what the
> synopsis notation has expressed.
>
> The comments on sharing a language feature, while
> likely helpful during review, seem verbose compared to
> the non-commenting in other similar files.
Thanks for the effort of preparing a patch.
However, I don't think that is an improvement:
- the comments pointing from MOVE to FETCH and vice versa are
helpful for people who edit the documentation like you did
- we should retain "empty or one of", otherwise the following syntax
would be undocumented:
FETCH FROM c;
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-07 03:39 rir <rirans@comcast.net>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 16+ messages in thread
From: rir @ 2021-10-07 03:39 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: rir <rirans@comcast.net>; pgsql-docs@lists.postgresql.org
On Mon, Oct 04, 2021 at 08:18:22AM +0200, Laurenz Albe wrote:
> On Fri, 2021-10-01 at 21:06 -0400, rir wrote:
> > Minor changes to move.sgml and fetch.sgml.
> >
> > The text 'or empty' is inconsistent by restating what the
> > synopsis notation has expressed.
> >
> > The comments on sharing a language feature, while
> > likely helpful during review, seem verbose compared to
> > the non-commenting in other similar files.
>
> Thanks for the effort of preparing a patch.
>
> However, I don't think that is an improvement:
>
> - the comments pointing from MOVE to FETCH and vice versa are
> helpful for people who edit the documentation like you did
> - we should retain "empty or one of", otherwise the following syntax
> would be undocumented:
>
> FETCH FROM c;
> Yours,
> Laurenz Albe
Laurenz,
Your view is completely reasonable, but it suggests that
many of the synopses are leaving syntax undocumented.
The 'empty or one of:' is only used in these two synopses.
If I had found the comments helpful, I would have spared them.
My sense was that the comments were unusual by their existence
for their purpose. That was not rigorous: so okay.
Since I'm only making the same points again, I'll stop.
Thanks again,
Rob
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-07 05:58 Laurenz Albe <laurenz.albe@cybertec.at>
parent: rir <rirans@comcast.net>
0 siblings, 1 reply; 16+ messages in thread
From: Laurenz Albe @ 2021-10-07 05:58 UTC (permalink / raw)
To: rir <rirans@comcast.net>; +Cc: pgsql-docs@lists.postgresql.org
On Wed, 2021-10-06 at 23:39 -0400, rir wrote:
> On Mon, Oct 04, 2021 at 08:18:22AM +0200, Laurenz Albe wrote:
> > On Fri, 2021-10-01 at 21:06 -0400, rir wrote:
> > > Minor changes to move.sgml and fetch.sgml.
> > >
> > > The text 'or empty' is inconsistent by restating what the
> > > synopsis notation has expressed.
> > >
> > > The comments on sharing a language feature, while
> > > likely helpful during review, seem verbose compared to
> > > the non-commenting in other similar files.
> >
> > Thanks for the effort of preparing a patch.
> >
> > However, I don't think that is an improvement:
> >
> > - the comments pointing from MOVE to FETCH and vice versa are
> > helpful for people who edit the documentation like you did
> > - we should retain "empty or one of", otherwise the following syntax
> > would be undocumented:
> >
> > FETCH FROM c;
>
> Your view is completely reasonable, but it suggests that
> many of the synopses are leaving syntax undocumented.
> The 'empty or one of:' is only used in these two synopses.
You have a point there.
Can you think of a way to modify the syntax diagram so that it
expresses that and still remains comprehensible?
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-07 20:06 rir <rirans@comcast.net>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 3 replies; 16+ messages in thread
From: rir @ 2021-10-07 20:06 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: rir <rirans@comcast.net>; pgsql-docs@lists.postgresql.org
On Thu, Oct 07, 2021 at 07:58:47AM +0200, Laurenz Albe wrote:
> On Wed, 2021-10-06 at 23:39 -0400, rir wrote:
> > On Mon, Oct 04, 2021 at 08:18:22AM +0200, Laurenz Albe wrote:
> > > On Fri, 2021-10-01 at 21:06 -0400, rir wrote:
> > > > Minor changes to move.sgml and fetch.sgml.
> > > However, I don't think that is an improvement:
> > >
> > > - the comments pointing from MOVE to FETCH and vice versa are
> > > helpful for people who edit the documentation like you did
> > > - we should retain "empty or one of", otherwise the following syntax
> > > would be undocumented:
> > >
> > > FETCH FROM c;
> >
> > Your view is completely reasonable, but it suggests that
> > many of the synopses are leaving syntax undocumented.
> > The 'empty or one of:' is only used in these two synopses.
> Can you think of a way to modify the syntax diagram so that it
> expresses that and still remains comprehensible?
For myself,
'FETCH [ <direction> [ FROM | IN ] ] <cursor_name>'
clearly indicates that 'direction' is optional.
Rob
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-07 20:18 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: rir <rirans@comcast.net>
2 siblings, 0 replies; 16+ messages in thread
From: Alvaro Herrera @ 2021-10-07 20:18 UTC (permalink / raw)
To: rir <rirans@comcast.net>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; pgsql-docs@lists.postgresql.org
On 2021-Oct-07, rir wrote:
> For myself,
> 'FETCH [ <direction> [ FROM | IN ] ] <cursor_name>'
> clearly indicates that 'direction' is optional.
Hmm, aren't you misreading the scope of the outer square brackets? If
<direction> is optional independently of [FROM|IN], then the synopsis
should be
FETCH [ <direction> ] [ FROM | IN ] <cursor_name>
and I think that's correct, since all forms omitting any of these are
accepted:
alvherre=# begin;
BEGIN
alvherre=*# declare c scroll cursor with hold for select 1 ;
DECLARE CURSOR
alvherre=*# commit;
COMMIT
alvherre=# fetch forward from c;
?column?
----------
1
(1 fila)
alvherre=# fetch from c;
?column?
----------
(0 filas)
alvherre=# fetch BACKWARD c;
?column?
----------
1
(1 fila)
alvherre=# fetch c;
?column?
----------
(0 filas)
--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-07 20:24 Tom Lane <tgl@sss.pgh.pa.us>
parent: rir <rirans@comcast.net>
2 siblings, 1 reply; 16+ messages in thread
From: Tom Lane @ 2021-10-07 20:24 UTC (permalink / raw)
To: rir <rirans@comcast.net>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; pgsql-docs@lists.postgresql.org
rir <rirans@comcast.net> writes:
> On Thu, Oct 07, 2021 at 07:58:47AM +0200, Laurenz Albe wrote:
>> Can you think of a way to modify the syntax diagram so that it
>> expresses that and still remains comprehensible?
> For myself,
> 'FETCH [ <direction> [ FROM | IN ] ] <cursor_name>'
> clearly indicates that 'direction' is optional.
Right, but if we don't say that <direction> can be
empty, then this diagram disallows
FETCH FROM cursor_name
which in fact is legal. I think however that we could make it read
FETCH [ <direction> ] [ FROM | IN ] <cursor_name>'
and have a correct description without requiring <direction>
to be allowed to be empty.
BTW, as it stands, the diagram is ambiguous
because there are two ways to parse
FETCH cursor_name
... is <direction> present but empty, or omitted altogether?
regards, tom lane
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-08 12:47 Laurenz Albe <laurenz.albe@cybertec.at>
parent: rir <rirans@comcast.net>
2 siblings, 2 replies; 16+ messages in thread
From: Laurenz Albe @ 2021-10-08 12:47 UTC (permalink / raw)
To: rir <rirans@comcast.net>; +Cc: pgsql-docs@lists.postgresql.org
On Thu, 2021-10-07 at 16:06 -0400, rir wrote:
> > > > - we should retain "empty or one of", otherwise the following syntax
> > > > would be undocumented:
>
> For myself,
> 'FETCH [ <direction> [ FROM | IN ] ] <cursor_name>'
> clearly indicates that 'direction' is optional.
Yes, but since [ FROM | IN ] is inside the bracket, that
diagram would not account for "direction" being omitted
while retaining FROM.
So I suggest that you change the syntax diagram to
FETCH [ direction ] [ FROM | IN ] cursor_name
Then I agree that the "empty or" can be removed.
I think that would be a good idea, and it would add
clarity.
I remain of the opinion that the comments should be
retained, but we can leave that for somebody else to
decide.
Do you want to prepare a new patch and register it in
the commitfest?
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-09 21:31 rir <rirans@comcast.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 16+ messages in thread
From: rir @ 2021-10-09 21:31 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: rir <rirans@comcast.net>; Laurenz Albe <laurenz.albe@cybertec.at>; pgsql-docs@lists.postgresql.org
On Thu, Oct 07, 2021 at 04:24:16PM -0400, Tom Lane wrote:
> rir <rirans@comcast.net> writes:
> > On Thu, Oct 07, 2021 at 07:58:47AM +0200, Laurenz Albe wrote:
> >> Can you think of a way to modify the syntax diagram so that it
> >> expresses that and still remains comprehensible?
>
> > For myself,
> > 'FETCH [ <direction> [ FROM | IN ] ] <cursor_name>'
> > clearly indicates that 'direction' is optional.
>
> FETCH FROM cursor_name
>
> which in fact is legal. I think however that we could make it read
>
> FETCH [ <direction> ] [ FROM | IN ] <cursor_name>'
>
> and have a correct description without requiring <direction>
> to be allowed to be empty.
> BTW, as it stands, the diagram is ambiguous
> because there are two ways to parse
>
> FETCH cursor_name
>
> ... is <direction> present but empty, or omitted altogether?
I am confident you know what you mean, but I don't. At the _parsing_
stage how is any distinction between emptiness and omission?
I can correct the patch to reflect the rightness of
FETCH [ <direction> ] [ FROM | IN ] <cursor_name>
in the sgml file and at least one misquote I have found.
Not being here that often, I will wait to see this conversation resolve.
Rob
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-09 21:42 Tom Lane <tgl@sss.pgh.pa.us>
parent: rir <rirans@comcast.net>
0 siblings, 0 replies; 16+ messages in thread
From: Tom Lane @ 2021-10-09 21:42 UTC (permalink / raw)
To: rir <rirans@comcast.net>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; pgsql-docs@lists.postgresql.org
rir <rirans@comcast.net> writes:
> On Thu, Oct 07, 2021 at 04:24:16PM -0400, Tom Lane wrote:
>> BTW, as it stands, the diagram is ambiguous
>> because there are two ways to parse
>> FETCH cursor_name
>> ... is <direction> present but empty, or omitted altogether?
> I am confident you know what you mean, but I don't. At the _parsing_
> stage how is any distinction between emptiness and omission?
Bison certainly makes a distinction, because it would have two different
production paths it could follow if the actual grammar looked like this
(which it doesn't). It doesn't care whether the emitted parse tree
would be the same. Indeed, it would be possible for the two cases to
create different parse trees.
regards, tom lane
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-10 20:15 rir <rirans@comcast.net>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
1 sibling, 2 replies; 16+ messages in thread
From: rir @ 2021-10-10 20:15 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: rir <rirans@comcast.net>; pgsql-docs@lists.postgresql.org
On Fri, Oct 08, 2021 at 02:47:43PM +0200, Laurenz Albe wrote:
> On Thu, 2021-10-07 at 16:06 -0400, rir wrote:
> So I suggest that you change the syntax diagram to
>
> FETCH [ direction ] [ FROM | IN ] cursor_name
> Then I agree that the "empty or" can be removed.
> I remain of the opinion that the comments should be
> retained, but we can leave that for somebody else to
> decide.
I accept your three points above.
The MOVE synopsis shows the same parsing as I presented,
should it be changed in the same way (move a square bracket left to
be after <direction>)? My guess is yes, but I've never used an
SQL cursor.
When this convo settles, I send a new patch. Probably
here in the group. If I have a few more, or a complex one,
I'll check out the other submission method.
Rob
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-11 06:57 Laurenz Albe <laurenz.albe@cybertec.at>
parent: rir <rirans@comcast.net>
1 sibling, 0 replies; 16+ messages in thread
From: Laurenz Albe @ 2021-10-11 06:57 UTC (permalink / raw)
To: rir <rirans@comcast.net>; +Cc: pgsql-docs@lists.postgresql.org
On Sun, 2021-10-10 at 16:15 -0400, rir wrote:
> On Fri, Oct 08, 2021 at 02:47:43PM +0200, Laurenz Albe wrote:
> > On Thu, 2021-10-07 at 16:06 -0400, rir wrote:
>
>
> > So I suggest that you change the syntax diagram to
> >
> > FETCH [ direction ] [ FROM | IN ] cursor_name
>
> > Then I agree that the "empty or" can be removed.
>
> > I remain of the opinion that the comments should be
> > retained, but we can leave that for somebody else to
> > decide.
>
> I accept your three points above.
>
> The MOVE synopsis shows the same parsing as I presented,
> should it be changed in the same way (move a square bracket left to
> be after <direction>)? My guess is yes, but I've never used an
> SQL cursor.
>
> When this convo settles, I send a new patch. Probably
> here in the group. If I have a few more, or a complex one,
> I'll check out the other submission method.
Yes, I think that such a patch would meet with favor.
Make sure to register it on the commitfest. To do that, it is better
to send the patch to the -hackers list. The commitfest application
won't find conversations on the -docs list.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-12 03:14 rir <rirans@comcast.net>
parent: rir <rirans@comcast.net>
1 sibling, 1 reply; 16+ messages in thread
From: rir @ 2021-10-12 03:14 UTC (permalink / raw)
To: rir <rirans@comcast.net>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; pgsql-docs@lists.postgresql.org
On Sun, Oct 10, 2021 at 04:15:01PM -0400, rir wrote:
> On Fri, Oct 08, 2021 at 02:47:43PM +0200, Laurenz Albe wrote:
> > On Thu, 2021-10-07 at 16:06 -0400, rir wrote:
> > FETCH [ direction ] [ FROM | IN ] cursor_name
Should the pgplsql docs be similiarly changed per the above
in 43.7.3.1 and 2?
Rob
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-12 06:43 Laurenz Albe <laurenz.albe@cybertec.at>
parent: rir <rirans@comcast.net>
0 siblings, 1 reply; 16+ messages in thread
From: Laurenz Albe @ 2021-10-12 06:43 UTC (permalink / raw)
To: rir <rirans@comcast.net>; +Cc: pgsql-docs@lists.postgresql.org
On Mon, 2021-10-11 at 23:14 -0400, rir wrote:
> On Sun, Oct 10, 2021 at 04:15:01PM -0400, rir wrote:
> > On Fri, Oct 08, 2021 at 02:47:43PM +0200, Laurenz Albe wrote:
> > > On Thu, 2021-10-07 at 16:06 -0400, rir wrote:
>
> > > FETCH [ direction ] [ FROM | IN ] cursor_name
>
> Should the pgplsql docs be similiarly changed per the above
> in 43.7.3.1 and 2?
Absolutely!
It may even make sense to extend the existing comments to
alert people who modify the syntax diagram in the future
that they should also consider reviewing the PL/pgSQL syntax.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-12 22:16 rir <rirans@comcast.net>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 0 replies; 16+ messages in thread
From: rir @ 2021-10-12 22:16 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: rir <rirans@comcast.net>; pgsql-docs@lists.postgresql.org
On Tue, Oct 12, 2021 at 08:43:34AM +0200, Laurenz Albe wrote:
> On Mon, 2021-10-11 at 23:14 -0400, rir wrote:
> > On Sun, Oct 10, 2021 at 04:15:01PM -0400, rir wrote:
> > > On Fri, Oct 08, 2021 at 02:47:43PM +0200, Laurenz Albe wrote:
> > > > On Thu, 2021-10-07 at 16:06 -0400, rir wrote:
> >
> > > > FETCH [ direction ] [ FROM | IN ] cursor_name
> >
> > Should the pgplsql docs be similiarly changed per the above
> > in 43.7.3.1 and 2?
>
> Absolutely!
>
> It may even make sense to extend the existing comments to
> alert people who modify the syntax diagram in the future
> that they should also consider reviewing the PL/pgSQL syntax.
I will make the syntax change.
Since my understanding is that, absent contrary documentation,
plpgSQL follows SQL, I resist the idea of yet another comment.
Better would be establishing a SPoT, tagging it, and tagging
various forms of derived info as quotes, code samples, etc. or,
at worst, logically dependent. This more form of commenting
could allow linting processes to support its use and check
its accuracy.
Absent that ...
Rob
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: small patch
@ 2021-10-12 22:44 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
1 sibling, 0 replies; 16+ messages in thread
From: Alvaro Herrera @ 2021-10-12 22:44 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: rir <rirans@comcast.net>; pgsql-docs@lists.postgresql.org
On 2021-Oct-08, Laurenz Albe wrote:
> I remain of the opinion that the comments should be
> retained, but we can leave that for somebody else to
> decide.
So I just realized that I added this comment in 8c250f3741f.
The point of this comment is that the list of options to which
"direction" expands is duplicate and needs to be kept in sync. However,
clearly we have other places in the docs where similar lists are
duplicated and no such comments are kept; see "column_constraint" in
alter_table.sgml and create_table.sgml for an obvious one. I can't
quite make up my mind about the comment being actually helpful if
somebody adds a new type of contraints to remind them that they also
need to add it to the other place. What do you think?
I think I side with Laurenz that the comment should be kept, even if
it's just out of inertia.
Maybe a better solution (more convoluted? overengineered?) would be to
define an SGML entity in the first of those pages that uses the list in
such a way so that it expands to that list, and then use that entity in
the other page. I don't know how that is done, but surely it must be
possible.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"E pur si muove" (Galileo Galilei)
^ permalink raw reply [nested|flat] 16+ messages in thread
end of thread, other threads:[~2021-10-12 22:44 UTC | newest]
Thread overview: 16+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-10-02 01:06 small patch rir <rirans@comcast.net>
2021-10-04 06:18 ` Laurenz Albe <laurenz.albe@cybertec.at>
2021-10-07 03:39 ` rir <rirans@comcast.net>
2021-10-07 05:58 ` Laurenz Albe <laurenz.albe@cybertec.at>
2021-10-07 20:06 ` rir <rirans@comcast.net>
2021-10-07 20:18 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2021-10-07 20:24 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-10-09 21:31 ` rir <rirans@comcast.net>
2021-10-09 21:42 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-10-08 12:47 ` Laurenz Albe <laurenz.albe@cybertec.at>
2021-10-10 20:15 ` rir <rirans@comcast.net>
2021-10-11 06:57 ` Laurenz Albe <laurenz.albe@cybertec.at>
2021-10-12 03:14 ` rir <rirans@comcast.net>
2021-10-12 06:43 ` Laurenz Albe <laurenz.albe@cybertec.at>
2021-10-12 22:16 ` rir <rirans@comcast.net>
2021-10-12 22:44 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
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