Thank you all for your fast response. I agree that back patching the
default change in general cases should be probably discussed in the hacker
mailing list to establish good practice. However, as a user, I would
typically just refer to the documentation of the specific version v11 in
this case ins
Hello!
https://www.postgresql.org/docs/current/catalog-pg-class.html says
"Columns used to form “replica identity” for rows: d = default (primary
key, if any), n = nothing, f = all columns i = index with indisreplident
set, or default". Am I wrong, or is there a missing comma (or other
punctu
> On 13 May 2020, at 12:20, Marina Polyakova wrote:
> https://www.postgresql.org/docs/current/catalog-pg-class.html says "Columns
> used to form “replica identity” for rows: d = default (primary key, if any),
> n = nothing, f = all columns i = index with indisreplident set, or default".
> Am I
Thanks!
P.S. Looking at the final sentence:
"Columns used to form “replica identity” for rows: d = default (primary
key, if any), n = nothing, f = all columns, i = index with
indisreplident set, or default"
in my opinion it's a little unclear what "or default" means at the end,
because the
Hi,
https://www.postgresql.org/docs/devel/pgstatstatements.html
In pg_stat_statements docs, the columns about WAL activity are put
in the table in the order of wal_bytes, wal_records and wal_fpi. But
in the definition of pg_stat_statements view, wal_bytes is put last.
So I think that it's better
Fujii Masao writes:
> In pg_stat_statements docs, the columns about WAL activity are put
> in the table in the order of wal_bytes, wal_records and wal_fpi. But
> in the definition of pg_stat_statements view, wal_bytes is put last.
> So I think that it's better to reorder those columns in a consist
On 2020/05/14 0:41, Tom Lane wrote:
Fujii Masao writes:
In pg_stat_statements docs, the columns about WAL activity are put
in the table in the order of wal_bytes, wal_records and wal_fpi. But
in the definition of pg_stat_statements view, wal_bytes is put last.
So I think that it's better to
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/12/tutorial-sql-intro.html
Description:
is wrong.
The four dots are not really a part of the path. Don't use them
literally. They indicate that you should use your local path inst
While working with TLS I noticed that the password callback definition had an
extra newline in the programlisting in the docs. Since the
has been indented with the textblock, the newline comes from whitespace being
significant. The attached 0001 fixes by instead anchoring on
column zero like ho
On Wed, May 13, 2020 at 05:17:43PM +0300, Marina Polyakova wrote:
> in my opinion it's a little unclear what "or default" means at the end,
> because the comma is used to separate enumeration elements ("d = default
> <...>, n = nothing, f = all columns, i = index <...>") and inside the
> element de
On Wed, May 13, 2020 at 11:07:44PM +0200, Daniel Gustafsson wrote:
> While working with TLS I noticed that the password callback definition had an
> extra newline in the programlisting in the docs. Since the
> has been indented with the textblock, the newline comes from whitespace being
> signifi
On 5/10/20 2:03 PM, Jonathan S. Katz wrote:
> On 5/10/20 12:27 PM, Tom Lane wrote:
>> Just FTR, here's a complete patch for this.
>
> Cool. I'll play around with it tonight once I clear out release work.
> Per upthread reference, I believe you've become a CSS maven yourself.
Time slipped a bit (
"Jonathan S. Katz" writes:
> Time slipped a bit (sorry!), but while prepping for the release I
> reviewed this. Visually, it looks WAY better. The code checks out too. I
> think any tweaks would be primarily around personal preference on the
> UI, so it may be better just to commit and get it out
13 matches
Mail list logo
