Thank you! Yeah, it seems fine. Sorry for the inconvenience
Nicola
> El 27 ago 2025, a la(s) 08:24, Peter Eisentraut
> escribió:
>
> On 27.08.25 04:49, PG Doc comments form wrote:
>> The following documentation comment has been logged on the website:
>> Page: https://www.postgresql.org/docs/
On 27.08.25 04:49, PG Doc comments form wrote:
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/17/wal-async-commit.html
Description:
within this document
https://www.postgresql.org/docs/current/wal-async-commit.html
in the paragraph tha
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/17/wal-async-commit.html
Description:
within this document
https://www.postgresql.org/docs/current/wal-async-commit.html
in the paragraph that says:
"before the WAL records it generated hav
Hello,
that is just the point:
cf
"
are that the materialized view cannot subsequently be directly updated
and that the query used to create the materialized view is stored in
exactly the same way that a view's query is stored, so that fresh data
can be generated for the materialized view with:
"
On Fri, Aug 22, 2025, at 23:40, David G. Johnston wrote:
> On Fri, Aug 22, 2025 at 2:23 PM PG Doc comments form
> wrote:
>> Unless I'm completely mistaken, the second code example on
>> https://www.postgresql.org/docs/current/rules-materializedviews.html, i.e
>> this:
>>
>> CREATE TABLE mymatvie
On Fri, Aug 22, 2025 at 2:23 PM PG Doc comments form
wrote:
> Unless I'm completely mistaken, the second code example on
> https://www.postgresql.org/docs/current/rules-materializedviews.html, i.e
> this:
>
> CREATE TABLE mymatview AS SELECT * FROM mytab;
>
> Should instead by
>
> CREATE VIEW mym
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/17/rules-materializedviews.html
Description:
Unless I'm completely mistaken, the second code example on
https://www.postgresql.org/docs/current/rules-materializedviews.html, i.e
this:
CREATE
sorry, my bad, thanks for the clarification!
вт, 21 січ. 2025 р., 18:40 користувач David G. Johnston <
david.g.johns...@gmail.com> пише:
> On Tue, Jan 21, 2025 at 10:39 AM Tom Lane wrote:
>
>> PG Doc comments form writes:
>> > EXPECTED:
>> > As shown here, the rank function produces a numerical
"David G. Johnston" writes:
> I was going to write basically that but something feels off to me. Maybe
> something like this:
> "As shown here, the rank function produces a numerical ranking within each
> partition, using the order defined by the ORDER BY clause. Ranking assigns
> the same rank
On Tue, Jan 21, 2025 at 10:39 AM Tom Lane wrote:
> PG Doc comments form writes:
> > EXPECTED:
> > As shown here, the rank function produces a numerical rank for each
> distinct
> > PARTITION BY value in the current row's partition, using the order
> defined
> > by the ORDER BY clause. rank needs
On Tue, Jan 21, 2025 at 10:39 AM Tom Lane wrote:
> PG Doc comments form writes:
> > EXPECTED:
> > As shown here, the rank function produces a numerical rank for each
> distinct
> > PARTITION BY value in the current row's partition, using the order
> defined
> > by the ORDER BY clause. rank needs
PG Doc comments form writes:
> EXPECTED:
> As shown here, the rank function produces a numerical rank for each distinct
> PARTITION BY value in the current row's partition, using the order defined
> by the ORDER BY clause. rank needs no explicit parameter, because its
> behavior is entirely determ
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/17/tutorial-window.html
Description:
EXPECTED:
As shown here, the rank function produces a numerical rank for each distinct
PARTITION BY value in the current row's partition, using the order
umentation page:
> https://www.postgresql.org/docs/current/sql-keywords-appendix.html
> there seems to be a typo where keyword END_EXEC is mistyped as END-EXEC.
> I am not myself familiar with this keyword but, if not a typo, this would
> make it the only hyphenated keyword and, therefore,
a typo where keyword END_EXEC is mistyped as END-EXEC.
I am not myself familiar with this keyword but, if not a typo, this would
make it the only hyphenated keyword and, therefore, a note should probably
be added to the entry stating that it is correctly spelled.
Thanks!
PG Doc comments form writes:
> In https://www.postgresql.org/docs/16/history.html#HISTORY-POSTGRESQL,
> Chapter 2.3. PostgreSQL is written in first sentence: "By 1996, it became
> clear that the name “Postgres95” would not stand the test of time."
> I think there should be "the rest of time" inste
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/history.html
Description:
In https://www.postgresql.org/docs/16/history.html#HISTORY-POSTGRESQL,
Chapter 2.3. PostgreSQL is written in first sentence: "By 1996, it became
clear that the na
the website:
>>
>> Page: https://www.postgresql.org/docs/16/parallel-plans.html
>> Description:
>>
>> In section 15.3.4, I believe "multiple results sets" is a typo for
>> "multiple
>> result sets". It says:
>>
>> > Plans
15.3.4, I believe "multiple results sets" is a typo for "multiple
result sets". It says:
> Plans that involve appending multiple results sets can therefore achieve
coarse-grained parallelism even when efficient partial plans are not
available.
It's also possible this sh
On Thu, Jul 25, 2024 at 9:50 AM PG Doc comments form
wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/16/parallel-plans.html
> Description:
>
> In section 15.3.4, I believe "multiple results sets&quo
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/parallel-plans.html
Description:
In section 15.3.4, I believe "multiple results sets" is a typo for "multiple
result sets". It says:
> Plans that involve appendin
On Sun, Apr 7, 2024 at 7:24 AM jian he wrote:
> On Sun, Apr 7, 2024 at 6:30 PM PG Doc comments form
> wrote:
> >
> > The following documentation comment has been logged on the website:
> >
> > Page: https://www.postgresql.org/docs/16/plpgsql-declarations.html
> > Description:
> >
> > Under 43.3.
"David G. Johnston" writes:
> On Saturday, April 6, 2024, PG Doc comments form
> wrote:
>> Under 43.3.1, "Notice that we omitted RETURNS real — we could have included
>> it, but it would be redundant."
>> Should that be "RETURNS tax" instead of "RETURNS real"?
> The docs are correct.
Specifical
On Sun, Apr 7, 2024 at 6:30 PM PG Doc comments form
wrote:
>
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/16/plpgsql-declarations.html
> Description:
>
> Under 43.3.1, "Notice that we omitted RETURNS real — we could have included
>
On Saturday, April 6, 2024, PG Doc comments form
wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/16/plpgsql-declarations.html
> Description:
>
> Under 43.3.1, "Notice that we omitted RETURNS real — we could have included
> it,
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/plpgsql-declarations.html
Description:
Under 43.3.1, "Notice that we omitted RETURNS real — we could have included
it, but it would be redundant."
Should that be "RETURNS tax" instead of "
On Fri, Mar 8, 2024 at 09:15:35PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/16/warm-standby.html
> Description:
>
> Section, 27.2.8.4. Planning For High Availability is missing the word "the"
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/warm-standby.html
Description:
Section, 27.2.8.4. Planning For High Availability is missing the word "the"
as shown below ..
"Such transaction commits may never be completed if any one of
PG Doc comments form writes:
> In the interval example outputs, for postgres and postgres_verbose.
> It says mons instead of months.
That is in fact the datatype's output format.
regression=# show intervalstyle;
IntervalStyle
---
postgres
(1 row)
regression=# select '2 month'::in
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/datatype-datetime.html
Description:
Hello,
In the interval example outputs, for postgres and postgres_verbose.
It says mons instead of months.
On Fri, Feb 15, 2019 at 07:51:31PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/10/runtime-config-wal.html
> Description:
>
> This page: https://www.postgresql.org/docs/10/runtime-config-wal.html
On Wed, Nov 01, 2023 at 09:18:47AM +0900, Michael Paquier wrote:
> So you mean something like the attached then?
Fixed that with f8b96c211da0 down to 11, in time for next week's
release set.
--
Michael
signature.asc
Description: PGP signature
On Tue, Oct 31, 2023 at 09:00:00PM +0300, Alexander Lakhin wrote:
> I don't remember details, but I think the primary reason for the change
> was that "RAISE_EXCEPTION" occurred in the whole tree only once (before
> 66bde49d96). Now I see, that I had chosen the wrong replacement — I agree
> with Eu
Hi Bruce,
31.10.2023 17:52, Bruce Momjian wrote:
It is referring to the internal constant (see src/backend/utils/errcodes.h). It
was like you are proposing and it was changed in
66bde49d96a9ddacc49dcbdf1b47b5bd6e31ead5. Reading the original thread, there is
no explanation why it was changed. R
king at the list of error codes (here
> https://www.postgresql.org/docs/current/errcodes-appendix.html) I think
> the
> "ERRCODE_RAISE_EXCEPTION (P0001)" is a typo and should remove "ERRCODE_"
> and
> simply read "RAISE_EXCEPTION (P0001)" or perhaps "
On Tue, Aug 23, 2022 at 02:38:13PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/14/runtime-config-error-handling.html
> Description:
>
> The second paragraph contains the sentence:
>
> > ...
Daniel Gustafsson writes:
>> On 7 Oct 2023, at 22:22, Tom Lane wrote:
>> Yeah, either way has the same result. However, I wonder if we should
>> change this example to use current_user for clarity. It does look
>> more like it's intended to be a variable or column reference than
>> a built-in f
> On 7 Oct 2023, at 22:22, Tom Lane wrote:
>
> "David G. Johnston" writes:
>> On Sat, Oct 7, 2023 at 11:11 AM Kirk Parker wrote:
>>> INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*; -- <= ARGUMENT IN
>>> QUESTION
>>> The emp_audit table has a column named 'userid', which in actual usage
>
On Sat, Oct 7, 2023 at 1:22 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Sat, Oct 7, 2023 at 11:11 AM Kirk Parker wrote:
> >> INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*; -- <= ARGUMENT IN
> QUESTION
> >> The emp_audit table has a column named 'userid', which in actual usage
"David G. Johnston" writes:
> On Sat, Oct 7, 2023 at 11:11 AM Kirk Parker wrote:
>> INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*; -- <= ARGUMENT IN
>> QUESTION
>> The emp_audit table has a column named 'userid', which in actual usage
>> (next-to-last line quoted) is populated by 'user' w
On Sat, Oct 7, 2023 at 11:11 AM Kirk Parker wrote:
>
> INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*; -- <=
> ARGUMENT IN QUESTION
> The emp_audit table has a column named 'userid', which in actual usage
> (next-to-last line quoted) is populated by 'user' which seems undefined
The PL/pgSQL page on triggers (
https://www.postgresql.org/docs/16/plpgsql-trigger.html ) contains the
following example (I'm excerpting only the essential parts here):
Example 43.4. A PL/pgSQL Trigger Function for Auditing
...
CREATE TABLE emp_audit(
operation char(1) NOT NULL
Daniel Gustafsson writes:
>> On 22 Sep 2023, at 19:04, Tom Lane wrote:
>> I propose the attached. (I also modified the para's last sentence to
>> speak of "kind" not "type", for consistency with the relkind field name
>> and the rest of the para.)
> LGTM.
Pushed, thanks for looking.
> On 22 Sep 2023, at 19:04, Tom Lane wrote:
>
> I wrote:
>> "Most" here is good English, although I concede it's a slightly
>> old-fashioned usage. Maybe it'd be clearer to just remove the
>> word altogether.
>
>> If we were going to touch this sentence I'd worry about some other
>> things too.
I wrote:
> "Most" here is good English, although I concede it's a slightly
> old-fashioned usage. Maybe it'd be clearer to just remove the
> word altogether.
> If we were going to touch this sentence I'd worry about some other
> things too. Use of "catalogs" as a verb is probably not the greates
Daniel Gustafsson writes:
>> On 20 Sep 2023, at 07:23, PG Doc comments form
>> wrote:
>> I've just read this:
>> "catalogs tables and most everything else that has columns or is otherwise
>> similar to a table"
>> It seems that it should be:
>> "catalogs tables and almost everything else that ha
> On 20 Sep 2023, at 07:23, PG Doc comments form wrote:
>
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/16/catalog-pg-class.html
> Description:
>
> I've just read this:
>
> "catalogs tables and most everything else that has colu
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/catalog-pg-class.html
Description:
I've just read this:
"catalogs tables and most everything else that has columns or is otherwise
similar to a table"
It seems that it should be:
"catal
On Tuesday, May 23, 2023, Tom Lane wrote:
> Laurenz Albe writes:
> > On Wed, 2023-05-24 at 07:32 +0900, Michael Paquier wrote:
> >> This is the current sentence, and it sounds kind of OK to me, FWIW:
> >> "Postgres95 code was completely ANSI C and trimmed in size by 25%.
>
> > That uses "ANSI C"
Laurenz Albe writes:
> On Wed, 2023-05-24 at 07:32 +0900, Michael Paquier wrote:
>> This is the current sentence, and it sounds kind of OK to me, FWIW:
>> "Postgres95 code was completely ANSI C and trimmed in size by 25%.
> That uses "ANSI C" as an adjective, which I think is sloppy wording
> (ev
On Wed, 2023-05-24 at 07:32 +0900, Michael Paquier wrote:
> On Tue, May 23, 2023 at 08:52:25PM +, PG Doc comments form wrote:
> > There appears to be a typo, here:
> > https://www.postgresql.org/docs/current/history.html#:~:text=Postgres95%20code%20was%20completely%20ANSI%20C
On Tue, May 23, 2023 at 3:32 PM Michael Paquier wrote:
> On Tue, May 23, 2023 at 08:52:25PM +, PG Doc comments form wrote:
> > There appears to be a typo, here:
> >
> https://www.postgresql.org/docs/current/history.html#:~:text=Postgres95%20code%20was%20completely%20ANSI%
On Tue, May 23, 2023 at 08:52:25PM +, PG Doc comments form wrote:
> There appears to be a typo, here:
> https://www.postgresql.org/docs/current/history.html#:~:text=Postgres95%20code%20was%20completely%20ANSI%20C.
> A word or two should be added between 'completely' and
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/15/history.html
Description:
Hi Folks, thank you for maintaining this great technical resource, which
I've only recently started to use.
There appears to be a typo, here:
> On 31 Mar 2023, at 14:35, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Reading this section I agree that the mix of ok/danger in the same example
>> can
>> be tad misleading though. Something like the attached is what I would prefer
>> as a reader.
>
> I think in your rewrite, "this que
Daniel Gustafsson writes:
> Reading this section I agree that the mix of ok/danger in the same example can
> be tad misleading though. Something like the attached is what I would prefer
> as a reader.
I think in your rewrite, "this query" is dangling a bit because there's
several sentences more
> On 28 Mar 2023, at 22:45, Tom Lane wrote:
>
> PG Doc comments form writes:
>> Page: https://www.postgresql.org/docs/15/explicit-locking.html
>
>> After the code snippet in the 6th paragraph of 13.3.5. Advisory Locks
>> (https://www.postgresql.org/docs/current/explicit-locking.html#ADVISORY-LO
PG Doc comments form writes:
> Page: https://www.postgresql.org/docs/15/explicit-locking.html
> After the code snippet in the 6th paragraph of 13.3.5. Advisory Locks
> (https://www.postgresql.org/docs/current/explicit-locking.html#ADVISORY-LOCKS)
> I believe there is a mistake in this sentence (I
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/15/explicit-locking.html
Description:
After the code snippet in the 6th paragraph of 13.3.5. Advisory Locks
(https://www.postgresql.org/docs/current/explicit-locking.html#ADVISORY-LOCKS)
I be
On 2023-02-15 13:44, Michael Paquier wrote:
On Tue, Feb 14, 2023 at 09:06:13AM +, Katsuragi Yuta wrote:
The parameter name "-Dtap-tests" in the meson's doc seems to be a
typo.
I think "-Dtap_tests" is the correct name. Attached patch fixes that.
I got an unkno
On Tue, Feb 14, 2023 at 09:06:13AM +, Katsuragi Yuta wrote:
> The parameter name "-Dtap-tests" in the meson's doc seems to be a typo.
> I think "-Dtap_tests" is the correct name. Attached patch fixes that.
>
> I got an unknown options error by
Hi,
The parameter name "-Dtap-tests" in the meson's doc seems to be a typo.
I think "-Dtap_tests" is the correct name. Attached patch fixes that.
I got an unknown options error by using "-Dtap-tests=enabled". However,
meson_options.txt told me the corre
PG Doc comments form writes:
> Near the end of Chapter 2.7 Aggregate Functions of the documentation, the
> command FILTER is introduced. The full query is
> SELECT city, max(temp_lo), count(*) FILTER (WHERE temp_lo < 30)
> FROM weather
> GROUP BY city
> HAVING max(temp_lo) < 40;
> an
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/15/tutorial-agg.html
Description:
Near the end of Chapter 2.7 Aggregate Functions of the documentation, the
command FILTER is introduced. The full query is
SELECT city, max(temp_lo), count(*
PG Doc comments form writes:
> In the documentation on
> https://www.postgresql.org/account/comments/new/15/indexes-multicolumn.html/
> Constraints on columns to the right of these columns are checked in the
> index, so they save visits to the table proper, but they do not reduce the
> portion of
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/15/indexes-multicolumn.html
Description:
In the documentation on
https://www.postgresql.org/account/comments/new/15/indexes-multicolumn.html/
```
Constraints on columns to the right of these
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/14/runtime-config-error-handling.html
Description:
The second paragraph contains the sentence:
> ...to ask the operating system to synchronize the whole file systems
that contain the dat
Daniel Gustafsson writes:
> Skimming the page I noticed that we wrap CSV in in all but a few
> places, which seemed randomly "chosen". Another sentence which stood out to
> me
> was this one on FREEZE:
> "This violates the normal rules of MVCC visibility and users specifying
> shou
> On 21 Aug 2022, at 20:48, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> On 21 Aug 2022, at 03:31, PG Doc comments form
>> wrote:
>>> ...so if you need to pass any arguments to shell command that come
>>> from an untrusted source...
>>>
>>> The "to shell command that come" part should be
Daniel Gustafsson writes:
> On 21 Aug 2022, at 03:31, PG Doc comments form wrote:
>> ...so if you need to pass any arguments to shell command that come
>> from an untrusted source...
>>
>> The "to shell command that come" part should be changed so it either reads
>> like this:
>>
>> ...so if yo
> On 21 Aug 2022, at 03:31, PG Doc comments form wrote:
>> ...so if you need to pass any arguments to shell command that come
> from an untrusted source...
>
> The "to shell command that come" part should be changed so it either reads
> like this:
>
>> ...so if you need to pass any arguments to
a minor typo:
> ...so if you need to pass any arguments to shell command that come
from an untrusted source...
The "to shell command that come" part should be changed so it either reads
like this:
> ...so if you need to pass any arguments to a shell command that comes
f
;
> > If no condition name nor SQLSTATE is specified in a RAISE EXCEPTION
> command, the default is to use ERRCODE_RAISE_EXCEPTION (P0001).
>
> Looking at the list of error codes (here
> https://www.postgresql.org/docs/current/errcodes-appendix.html) I think the
> "ERRCO
rent/errcodes-appendix.html) I think the
"ERRCODE_RAISE_EXCEPTION (P0001)" is a typo and should remove "ERRCODE_" and
simply read "RAISE_EXCEPTION (P0001)" or perhaps "ERRCODE =
'RAISE_EXCEPTION'" since that's how the default behaviour would be written
in a RAISE statement.
Many thanks,
Eric Mutta.
On Thu, Jul 07, 2022 at 12:27:01AM +, PG Doc comments form wrote:
> Towards the end of the section, the code examples given have comments where
> the JSON is using single quotes instead of double quotes around the
> properties. For example this:
>
> -- Where jsonb_field was {}, it is now {
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/14/datatype-json.html
Description:
Towards the end of the section, the code examples given have comments where
the JSON is using single quotes instead of double quotes around the
properties.
> On 31 Jan 2022, at 23:05, Tom Lane wrote:
> It's hard to explain why lo_creat is there at all without mentioning
> 8.1, so I ended up with the below, which basically says that lo_creat
> is only useful for talking to pre-8.1 servers.
Agreed, makes sense.
> Comments?
LGTM.
--
Daniel Gustaf
Daniel Gustafsson writes:
>> On 30 Jan 2022, at 16:52, Tom Lane wrote:
>> I could get behind documenting the more modern
>> one first, though.
> +1
Proposed patch attached.
>> I wonder if it's time to remove the references to PG 8.1?
> I think it's time to remove references to 8.0 and 8.1 to
> On 30 Jan 2022, at 16:52, Tom Lane wrote:
> I could get behind documenting the more modern
> one first, though.
+1
> I wonder if it's time to remove the references to PG 8.1?
I think it's time to remove references to 8.0 and 8.1 to de-clutter the page,
8.3 or 8.4 seems like a better lower li
Magnus Hagander writes:
> It might be worth splitting that part into one section with the
> current function (lo_create) and then a separate section with the
> backwards-compatible lo_creat function though -- I can see how it's
> easy to come to the conclusion you did from reading it, and that cou
On Sun, Jan 30, 2022 at 1:39 PM PG Doc comments form
wrote:
>
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/10/lo-interfaces.html
> Description:
>
> I assume "inv_oid = lo_creat(conn, INV_READ|INV_WRITE);" should be "inv_oid
> = lo_
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/10/lo-interfaces.html
Description:
I assume "inv_oid = lo_creat(conn, INV_READ|INV_WRITE);" should be "inv_oid
= lo_create(conn, INV_READ|INV_WRITE);", right?
https://www.postgresql.org/docs/
docs -
they really make a difference to those of us coming from other (commerical)
databases!
On Wed, Jan 19, 2022, 02:28 David G. Johnston
wrote:
> On Tue, Jan 18, 2022 at 4:01 PM Eric Mutta wrote:
>
>>
>> 2. I noticed the typo and on the top right of the page there's an &q
On Tue, Jan 18, 2022 at 4:01 PM Eric Mutta wrote:
>
> 2. I noticed the typo and on the top right of the page there's an "edit"
> link. Click that and it takes you to GitHub where the Markdown text is.
>
I suspect a large part of your expectation is based upon this
a few
clicks from start to finish. Here's the flow from a real example:
1. There was a typo in the "Restore and Recovery Overview (SQL Server)"
docs here
https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-and-recovery-overview-sql-server?view=sql-ser
wondering is there anything similar for the Postgres docs?
>
> Going through a mailing list just to fix a typo feels like a lot of overhead!
Hi!
Personally, I would find sending an email to a mailing list or like
you did, filling out the form on the website, would be *less* overhead
than hav
t; wondering is there anything similar for the Postgres docs?
>
> Going through a mailing list just to fix a typo feels like a lot of overhead!
No, sorry, there is not an easier way.
--
Bruce Momjian https://momjian.us
EDB https://enterprise
list just to fix a typo feels like a lot of
overhead!
On Sun, Jan 2, 2022, 19:08 Magnus Hagander wrote:
> On Mon, Dec 27, 2021 at 12:07 AM PG Doc comments form
> wrote:
> >
> > The following documentation comment has been logged on the website:
> >
> > Page: https://w
On Mon, Dec 27, 2021 at 12:07 AM PG Doc comments form
wrote:
>
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/14/warm-standby.html
> Description:
>
> The following sentence:
>
> > The minimum wait time is the round-trip time **betwee
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/14/warm-standby.html
Description:
The following sentence:
> The minimum wait time is the round-trip time **between primary to
standby.**
Should either end with "...between primary AND stand
On Thu, 23 Sep 2021, 16:45 Tom Lane, wrote:
>
> No, "memoize" is the intended spelling.
>
> regards, tom lane
Oh, my bad. Cool new term. Thanks.
Erwin Brandstetter writes:
> https://www.postgresql.org/docs/14/release-14.html#id-1.11.6.5.5.3.7
>> Add executor method to memoize results from the inner side of a
> nested-loop join (David Rowley)
> ->
> Add executor method to memorize results from the inner side of a
> nested-loop join (David
> On 23 Sep 2021, at 16:26, Erwin Brandstetter wrote:
>
> https://www.postgresql.org/docs/14/release-14.html#id-1.11.6.5.5.3.7
>
> > Add executor method to memoize results from the inner side of a nested-loop
> > join (David Rowley)
>
> ->
> Add executor method to memorize results from the inn
https://www.postgresql.org/docs/14/release-14.html#id-1.11.6.5.5.3.7
> Add executor method to memoize results from the inner side of a
nested-loop join (David Rowley)
->
Add executor method to memorize results from the inner side of a
nested-loop join (David Rowley)
Regards
Erwin
> That sentence is a suggestion of an action for the reader to take,
conditionally upon verifying that such things are no longer necessary.
I see, that makes sense now, I was parsing the sentence differently.
Perhaps for clarity those explicit locks could be mentioned in brackets so
the sentence r
PG Doc comments form writes:
> The following sentence:
>> Eliminate explicit locks, SELECT FOR UPDATE, and SELECT FOR SHARE where no
> longer needed due...
> Uses the word "where" when it should probably use the word "are" and thus
> read:
> Eliminate explicit locks, SELECT FOR UPDATE, and SELE
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/13/transaction-iso.html
Description:
The following sentence:
> Eliminate explicit locks, SELECT FOR UPDATE, and SELECT FOR SHARE where no
longer needed due...
Uses the word "where" when it
>"were not" is typical usage when stating a contrary-to-fact hypothetical.
> If the implementation (or you) didn’t do X, then Y bad thing could happen.
Really thanks for your kindly reply and explain.
Please forgive me for my poor English. Anyway, got it.
Regards,
Tang
t...@sss.pgh.pa.us wrote:
> PG Doc comments form writes:
>
>> small fix in description at [1] as follows
>
>> -If that were not done interrupted code that's currently inspecting errno
>> might see the wrong value.
>> +If that was not done interrupted code that's currently inspecting errno
>> mi
PG Doc comments form writes:
> small fix in description at [1] as follows
> -If that were not done interrupted code that's currently inspecting errno
> might see the wrong value.
> +If that was not done interrupted code that's currently inspecting errno
> might see the wrong value.
The existing
1 - 100 of 246 matches
Mail list logo
