Re: nchar is undocumented

By the way, this neighboring sentence is a bit awkward " It must be ... or a type for which there is a cast from json to that type." Would it be better to say " It must be ... or a type to which a cast from json exists." ? -- Álvaro Herrera 48°01'N 7°57'E —

Re: nchar is undocumented

On 2024-May-05, David Rowley wrote: > On Sun, 5 May 2024 at 12:41, Erik Wienhold wrote: > > So, I think we should either remove that one nchar instance (because it > > doesn't add any real value) or document it properly. The attached patch > > does the latter. > > It seems easier to do the

Re: nested tags in glossary entries in html docs

On 2024-Apr-25, Jürgen Purtz wrote: > Great recommendation. I may have time in the second half of June to > pursue the migration further. There is  a performance problem, which > possibly results from our XSLT script that optimizes the > transformation-speed and works well in 4.x. Maybe a way to

Re: nested tags in glossary entries in html docs

On 2024-Apr-12, Erik Wienhold wrote: > There's this bug[1] in the DocBook XSLT stylesheets. Looks like the > fix[2] landed in 1.79.2 (latest version on Arch, Maybe one of these days we should get going with the migration to Docbook 5.x that Jürgen Purtz proposed.

Re: wal_init_zero / wal_recycle

On 2024-Apr-24, Peter Eisentraut wrote: > On 24.04.24 10:08, Nicolas Seinlet wrote: > > It was not crystal clear to me that when wal_recycle is also ON , the > > recycled files are not filled with zeroes, because they are not > > considered as new. Could we add a sentence stating this? > > It

Re: Non-blocking synchronization in libpq using pipeline mode

On 2024-Mar-06, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/libpq-pipeline-mode.html > Description: > > The calls to PQpipelineSync and PQsendFlushRequest may either report failure > or success,

Re: Broken link

On 2024-Feb-06, Daniel Gustafsson wrote: > > On 5 Feb 2024, at 22:23, PG Doc comments form > > wrote: > > > This page has a link that says "See the release notes for PostgreSQL 12 for > > details on this change." > > https://www.postgresql.org/docs/current/recovery-config.html > > > > The

Re: SQL command : ALTER DATABASE OWNER TO

On 2024-Jan-24, Laurenz Albe wrote: > The permissions are transferred to the new owner, so the old owner doesn't > have any privileges on the object (and, in your case, cannot connect to > the database any more). However, if the old owner had a pg_hba.conf line that allowed them in, and the new

Re: Spam complaint

On 2024-Jan-24, Laurenz Albe wrote: > For months now, I have received this automated reply whenever I post to > this list: Yeah, me too -- the oldest I can find is 27th November last year, but it's quite possible that I deleted older ones without leaving traces. I unsubscribed this address now,

Re: "name" vs "alias" in datatype table

On 2023-Nov-29, Tom Lane wrote: > Eric Hanson writes: > > The larger point being, the "name" vs "alias" paradigm presented in this > > table does not accurately represent PostgreSQL, and conveys an inaccurate > > picture of the relationship between type names. int4 is not an "alias". > > I

Re: CONCURRENTLY in example of index of partitioned table

On 2023-Nov-27, Nikolay Samokhvalov wrote: > https://www.postgresql.org/docs/current/ddl-partitioning.html provides an > example of using CONCURRENTLY for index creation of partitioned tables; but > it the example itself doesn't have this word; here is a fix: You're right, my mistake. Will push

Re: [DOCS] Add example about date ISO format

On 2023-Nov-27, Erik Wienhold wrote: > Two issues that I fixed in the attached patch: > > * it's called "extended format" not "T format" (the "T" is mandatory > anyway) +1 > * the time zone was missing from the result output This is wrong. Actually, there's no timezone in value, because

Re: [DOCS] Add example about date ISO format

On 2023-Nov-22, Laurenz Albe wrote: > I think the example had best be at "8.5.2. Date/Time Output", in > doc/src/sgml/datatype.sgml around line 2552. Actually, isn't that a strange location? Chapter 8.5.2 is about the datatype itself, and there's already a cross-link to Section 9.8 for

Re: add new acronym "AM"

On 2023-Nov-13, Daniel Gustafsson wrote: > That's a fair point. It's sort of hard to refer back from the acronym list > though since we don't have a single Access Method section but instead one for > Indexes and one for Relations. In the attached diff I propose that we add a > glossary entry

Re: SP-GiST confusing introductory paragraph

On 2023-Oct-16, PG Doc comments form wrote: > I'm confused by this paragraph: > > > These popular data structures were originally developed for in-memory > > usage. In main memory, they are usually designed as a set of dynamically > > allocated nodes linked by pointers. This is not suitable for

Re: 31.7.1. Initial Snapshot

On 2023-Oct-11, David G. Johnston wrote: > Or move 4 paragraphs of introductory material into its own section so that > there are two sections and a brief sentence for an intro. We have lots of other places where this (single-entry TOCs) happens. I don't think we want to add spurious tags in

Re: 31.7.1. Initial Snapshot

On 2023-Oct-11, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/logical-replication-architecture.html > Description: > > There are dublicated section named "31.7.1. Initial Snapshot" on >

Re: Hyperlinks for source file references

On 2023-Sep-25, Daniel Gustafsson wrote: > This does of course present a question for the backbranches, pointing to the > HEAD version in the docs for a previous major release isn't entirely accurate. > On the other hand, we already do that today in the above tableam page so if we > don't like

Re: Postgres 14 documentation suggests range_agg is available, but it's not until Postgres 15

On 2023-May-19, Alvaro Herrera wrote: > On 2023-May-18, PG Doc comments form wrote: > > > I noticed that range_agg is listed in the Postgres 14 documentation as an > > available aggregate function here: > > https://www.postgresql.org/docs/14/functions-aggregate.h

Re: Postgres 14 documentation suggests range_agg is available, but it's not until Postgres 15

On 2023-May-18, PG Doc comments form wrote: > I noticed that range_agg is listed in the Postgres 14 documentation as an > available aggregate function here: > https://www.postgresql.org/docs/14/functions-aggregate.html > > However, my understanding is that this feature isn't available until >

Re: some new glossary entries

On 2023-May-02, Daniel Gustafsson wrote: > + > + LSN > + > + > > The other entries doesn't have a glossentry id > attribute set, is the use here related to the glossentry.show.acronym param? I debated with myself for 347d2b07fcc2 on whether to add id attribs to entries. The only

Re: The use "Postgres" in docs

On 2023-Mar-14, Daniel Gustafsson wrote: > The docs use PostgreSQL and not Postgres in all but two places, which I think > we should change like in the attached to be consistent. Any objections to > this? Both are very new. No objection to the change. -- Álvaro HerreraBreisgau,

Re: Fix broken event trigger example

On 2022-Dec-23, Laurenz Albe wrote: > The example in > https://www.postgresql.org/docs/current/event-trigger-example.html > stopped compiling since commit 2f9661311b. > > Here is a patch to fix that. Right, thanks. Applied to all the relevant branches. -- Álvaro Herrera PostgreSQL

Re: Merge statement

On 2022-Nov-18, Boboc Cristi wrote: >     Dear David, your suggestion would be good if it could be applied. > > I have not found the setting you are talking about. I attach here a > screenshot of the settings page. Since obviously you are more > experimented than me about the mail clients, please

Re: Merge statement

On 2022-Nov-17, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/15/sql-merge.html > Description: > > From the description it looks like a single WHEN clause is accepted, which > is definitely not true.

Re: Usability ideas: text width and headers that are links

On 2022-Oct-21, Niels Bom wrote: > Setting a max-width on regular textual content is good for > readability, which in turn increases accessibility. See this W3C a11y > documentation (1) and an a11y page by the US government (2) for more > detailed info. > > Using the CSS max-width property makes

Re: Missing documentation

On 2022-Nov-03, Tom Lane wrote: > Stefan Badenhorst writes: > > I am using a prometheus exporter: > > https://github.com/prometheus-community/postgres_exporter/ > > Hmm, well, maybe prometheus is doing something with that part of the URL. > There's no such behavior in Postgres itself, though.

Re: Comparison Predicates - example - documentation seems contradictory?

On 2022-Oct-06, PG Doc comments form wrote: > See the heading: "Table 9.2. Comparison Predicates" > > "2 BETWEEN 3 AND 1 → f" # ok this is false. > > But let's read the example immediately below (the 'not between' example) > > 2 NOT BETWEEN 1 AND 3 → f # what? This is also false. how can the

Re: DocBook 5.2

On 2022-Sep-05, Jürgen Purtz wrote: > - > + >    User-Defined Types OK, these seem quite significant changes that are likely to cause great pain. So I repeat my question, what are the benefits of making this change? They better be very very substantial. -- Álvaro HerreraBreisgau,

Re: DocBook 5.2

On 2022-Sep-04, Jürgen Purtz wrote: > DocBook 5.2 is around the corner [1], we use DocBook 4.5 which is 'feature > frozen' since 2006, and there are even ideas for DocBook 6.x [2]. What changes? I doubt we'll want to adopt a new version immediately after release, since we want to stay

Re: Section 40.1 Overview of Event Trigger Behavior, and Table 40.1 missing needed details

On 2022-Aug-27, PG Doc comments form wrote: > Section 40.1. Overview of Event Trigger Behavior says: > "The table_rewrite event occurs just before a table is rewritten by some > actions of the commands ALTER TABLE and ALTER TYPE." > Issue: Neither the section nor the table describe which actions

Re: relpages in pg_class

On 2022-Aug-19, Bruce Momjian wrote: > On Fri, Aug 19, 2022 at 04:10:30AM +, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/14/catalog-pg-class.html > > Description: > > > > From source code,

Re: Documentation Suggestion

On 2022-Jul-21, Bruce Momjian wrote: > Patch applied to all supported branches. Thanks, looks good. I notice you credited me as the reporter, but actually the reporter is jheb...@micron.com. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/

Re: list of flags that pg_settings_get_flags reports

Hello On 2022-Jul-20, Fujii Masao wrote: > Attached is the updated version of the patch. It separates the list > for GUC flags from the table entry for pg_settings_get_flags() and > adds the table for it at the bottom of the existing function table. I lament the fact that the version of DocBook

Re: list of flags that pg_settings_get_flags reports

On 2022-Jul-15, Fujii Masao wrote: > Hi, > > In the docs, the display of the list of flags that > pg_settings_get_flags reports looks a bit odd to me [*1]. To make it > smarter, how about using instead of , to > list thoes flags within ? Patch attached. I think it should be a separate table,

Re: proposal: convert comments in documents to html comments

On 2022-Jun-27, Noboru Saito wrote: > > I don't have much of a clue about our docbook toolchain, beyond the > > basics (plus I have no front-end experience). Is anybody else aware of > > a reasonable approach to making git hashes discoverable from the html > > release notes? > > If you simply

Re: INVALID index while concurrent indexing in progress?

On 2022-May-20, Laurenz Albe wrote: > Alvaro meant that my message already contained a patch, so there is no need to > send another one, unless you have a different suggestion. Right. Being old-school, I can just save the email to a plain text file and do "patch < /tmp/emailfile". 'patch' has

Re: INVALID index while concurrent indexing in progress?

On 2022-May-19, Rajakavitha Kodhandapani wrote: > Thank you, Laurenz. The changes that you suggested make a lot more sense. > I will make the updates and submit the changes. Hmm, but they're already submitted. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "La

Re: Documentation Suggestion

I pushed the other suggested bits. On 2022-May-13, Bruce Momjian wrote: > On Fri, Apr 29, 2022 at 10:06:57AM -0400, Tom Lane wrote: > > I don't think this is an improvement, mainly for the reason David > > mentions: why wouldn't you need a similar statement on every single > > one of our

Re: BETWEEN operator not indexed

On 2022-May-03, Daniel Gustafsson wrote: > A wild guess; perhaps between is defined in a stopwords list for searching > somewhere? Our very own src/backend/snowball/stopwords/english.stop contains it. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/

Re: Documentation Suggestion

gamos" (A. Schopenhauer) >From ad7baac914aa306ac419d3b76495b45958df0e85 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Fri, 29 Apr 2022 10:55:43 +0200 Subject: [PATCH] case-sensitivity note in initdb --- doc/src/sgml/ref/initdb.sgml | 18 -- 1 file changed, 16 insertions(+)

Re: 43.10 Trigger Functions one sentences kind of not easy to understand.

On 2022-Apr-27, Jian He wrote: > https://www.postgresql.org/docs/current/plpgsql-trigger.html > > > *Returning a row value different from the original value > > of NEW alters the row that will be inserted or updated.* > I just want confirm the highlighted sentence is equivalent as the >

Re: Add further details to ROW SHARE table level lock modes section

On 2022-Apr-04, PG Doc comments form wrote: > I propose that it would be useful to explicitly state that `SELECT FOR KEY > SHARE` AND `SELECT FOR NO KEY UPDATE` commands also acquire the ROW SHARE > table level lock on target table(s). That is: > ``` > Conflicts with the EXCLUSIVE and ACCESS

Re: pg_dump shared locks documentation

On 2022-Mar-15, Florin Irion wrote: > In the `pg_dump` documentation we talk about "shared locks", but IIUC, > we actually take `AccessShareLock`s. This might be misunderstood with > the `ShareLock`. This might be a bit excessive to have in the main text. What about adding a footnote to point

Re: Conventions

On 2022-Jan-26, Bruce Momjian wrote: > On Tue, Jan 25, 2022 at 06:45:47PM -0800, Dave Stewart wrote: > > I'm good with it.  Thank you! > > OK, updated patch attached. I don't think we even show TCL syntax > anywhere anymore, so I removed that text, rather than moving it. We do here:

Re: ALTER TABLE ... SET DATA TYPE removes statistics

On 2021-Oct-26, nikolai.berkoff wrote: > Thank you, this reads better. > Is there a reason in the docs there is sometimes > > ANALYZE > > and sometimes only > > ANALYZE > ? I prefer the link if there is no hard rule. I pushed this on November 5th; it is commit

Re: max_slot_wal_keep_size unit is not specified

On 2021-Nov-26, Kyotaro Horiguchi wrote: > Regarding the proposed description, we have never explained how the > same kind of values specified in megabytes is converted into internal > units. If we add that explanation there, we might want the same for > max_wal_size, min_wal_size and

Re: max_slot_wal_keep_size unit is not specified

On 2021-Nov-24, Kyotaro Horiguchi wrote: > At Tue, 23 Nov 2021 11:21:05 -0300, Alvaro Herrera > wrote in > > I wonder why did we make it round down rather than up. Does this mean > > that if you have max_slot_wal_keep_size=8MB and wal segments of 16 MB, > > t

Re: max_slot_wal_keep_size unit is not specified

On 2021-Nov-22, PG Doc comments form wrote: > The unit (I assume it's MB) of max_slot_wal_keep_size is not explicitly > specified in the docs. If it's intentional then please, disregards, but I've > not been able to deduct that from this page alone. Thanks! Well, that's embarrasing. I'll see

Re: vacuumdb --analyze-in-stages

On 2021-Oct-26, nikolai.berkoff wrote: > Given all the suggestions I've tried to combine them into one patch again. OK, I pushed something very similar but not exactly your patch ... please have a look if you care to suggest improvements. ... oh, I just noticed I made a typo -- omitted "with"

Re: Correction for vacuum_multixact_failsafe_age

On 2021-Oct-28, Pavel Luzanov wrote: > Hi, > > > Agreed. Pushed Pavel's patch just now. > > Sorry, I didn't check it right away. > But it makes sense to backport to v14, where vacuum_multixact_failsafe_age > was introduced. It is in 14. Author: Peter Geoghegan Branch: master [00c61a74b]

Re: documentation describing the range of a number type 'integer' is incorrect

On 2021-Oct-22, Kevin Sweet wrote: >The bugs team agreed that it's a bug. The documentation accurately >represents the buggy code. I thought you might want to update the doc >when the bug is fixed. It looks like the bug and the docs have both been fixed for months. I just somehow

Re: documentation describing the range of a number type 'integer' is incorrect

On 2021-Jul-29, PG Doc comments form wrote: > https://www.postgresql.org/docs/13/datatype-numeric.html says that the range > of a numeric type integer is -2147483648 to +2147483647 but > PGTYPESnumeric_to_int considers -2147483648 (a perfectly valid 32-bit > integer) to be invalid because it

Re: ALTER TABLE ... SET DATA TYPE removes statistics

On 2021-Oct-19, Michael Paquier wrote: > On Mon, Oct 18, 2021 at 05:15:59PM -0300, Euler Taveira wrote: > > I agree that it might surprise an user and it would be good to document it. > > However, it does not belong to the description. I would add it to the Notes > > section at the end of the

Re: vacuumdb --analyze-in-stages

On 2021-Oct-18, David G. Johnston wrote: > On Mon, Oct 18, 2021 at 4:02 PM Alvaro Herrera > wrote: > > Given that the first stage uses statistic target=1, running this option > > in a database with any stats at all is probably a bad idea. > > Add the word "only"

Re: vacuumdb --analyze-in-stages

On 2021-Oct-18, Euler Taveira wrote: > On Fri, Oct 8, 2021, at 6:33 AM, nikolai.berkoff wrote: > > Running --analyze-in-stages on a database with statistics causes the > > statistics to become significantly worse before they are improved. > > This could be made clearer in the documentation. > > I

Re: small patch

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"

Re: Correction for vacuum_multixact_failsafe_age

On 2021-Oct-12, Pavel Luzanov wrote: > Hello, > > > > When trying to make a link to the new vacuum_multixact_failsafe_age > > > parameter, > > > I found the wrong ID for this guc (missed word vacuum). > > > Please consider this patch for a fix. > > It is good to be consistent, but the name of

Re: small patch

On 2021-Oct-07, rir wrote: > For myself, >'FETCH [ [ FROM | IN ] ] ' > clearly indicates that 'direction' is optional. Hmm, aren't you misreading the scope of the outer square brackets? If is optional independently of [FROM|IN], then the synopsis should be FETCH [ ] [ FROM | IN ] and

Re: Link t the souce code

On 2021-Jul-21, Tom Lane wrote: > Alvaro Herrera writes: > > Well, we can remove that first paragraph from there and just refer the > > reader to the appendix ... something like this, perhaps. > > +1, though I think you're short a or so. Two markup errors actually, an

Re: Link t the souce code

On 2021-Jul-21, Tom Lane wrote: > Hm ... actually, now that I read the committed patch, I realize that > it's effectively recommending that people build their installations > from the latest commit on master. That might be what aspiring PG > hackers want to do, but it's quite unlikely that Joe

Re: Link t the souce code

On 2021-Jul-21, Tom Lane wrote: > Alvaro Herrera writes: > > That means we can remove the `gunzip` line and replace it with nothing. > > WFM ... > > WFM too. The other thing I wonder about is whether the example shouldn't > be assuming that you chose the .bz2 fil

Re: Link t the souce code

On 2021-Jul-21, Peter Eisentraut wrote: > On 21.07.21 01:45, Alvaro Herrera wrote: > > > > -gunzip postgresql-.tar.gz > > -tar xf postgresql-.tar > > +tar xfa postgresql-.tar.gz > > > > The "a" option only applies when creating a tar archiv

Re: Link t the souce code

On 2021-May-06, Tom Lane wrote: > Alvaro Herrera writes: > > 3. add a separate paragraph that says to obtain the source from the > > other dir if it's the development one. > > I kinda prefer the last one, because then we could also suggest to use a > > Git repo in

Re: 24.1.5.1. Multixacts And Wraparound

On 2021-Jun-24, Bruce Momjian wrote: > + As a safety device, an aggressive vacuum scan will > + occur for any table whose multixact-age (see + linkend="vacuum-for-multixact-wraparound"/>) is greater than + linkend="guc-autovacuum-multixact-freeze-max-age"/>. Also, if the > +

Re: Reverse btree indexes

On 2021-Jun-22, David G. Johnston wrote: > On Tue, Jun 22, 2021 at 2:28 PM Zach Aysan wrote: > >> for example, col LIKE 'foo%' or col ~ '^foo', but not col LIKE '%bar', > >> which would require a reversed index on the field. To use the reversed > >> index, query with reverse(col) like

Re: Simplify COMMENT and SECURITY LABEL documentation

On 2021-Jun-02, Peter Eisentraut wrote: > On 01.06.21 17:56, Alvaro Herrera wrote: > > > +1 for the concept, but I feel that "live in" is a bit too informal > > > for this context. I'm too caffeine-deprived to instantly come up > > > with le mot

Re: Simplify COMMENT and SECURITY LABEL documentation

On 2021-Jun-01, Tom Lane wrote: > Peter Eisentraut writes: > > ... I wonder if it would be more practical to just write: > > > The name of the object to be commented. Names of objects that live > > in schemas (tables, functions, etc.) can be schema-qualified. > > +1 for the

Re: Unsupported version mentioned at Using EXPLAIN

On 2021-May-07, tanghy.f...@fujitsu.com wrote: > Hi > > When referring Doc, found one place mentioned "using 9.3 development > sources." at [1]. Which I think 9.3 means PG9.3 > > [1] > https://www.postgresql.org/docs/current/using-explain.html > > It seems to show up since PG9.2 and changed

Re: Link t the souce code

On 2021-May-06, Jonathan S. Katz wrote: > On 5/6/21 6:05 PM, Tom Lane wrote: > > Alvaro Herrera writes: > >> I agree -- if the user wanted packages, they would not be reading that > >> page of the docs. I'd just have it point to the same page that the > >>

Re: Link t the souce code

Hello On 2021-May-04, Daniel Westermann (DWE) wrote: > reading this: https://www.postgresql.org/docs/13/install-getsource.html > ... > I wonder if the link should not directly point to the relevant release, e.g.: > https://www.postgresql.org/ftp/source/v13.2/ > > To me that seems to be more

Re: "there is no way to insert less than one row"

On 2021-Mar-24, David G. Johnston wrote: > On Wed, Mar 24, 2021 at 1:29 PM Peter Eisentraut < > peter.eisentr...@enterprisedb.com> wrote: > > > On 20.03.21 20:16, PG Doc comments form wrote: > > > So, the last insert command inserted zero rows. What is meant by "there > > is > > > no way to

Re: The sub-categories do not have anchors on this page

On 2020-Dec-10, Steven Pousty wrote: > They certainly do at the top of the page, that's why I sent the second > email. I was hoping to have anchors down the page where that actual topic > is. The rational for this is, when I write a blog post, teach a class, help > someone on slack... I can give

Re: The sub-categories do not have anchors on this page

Hello On 2020-Dec-02, PG Doc comments form wrote: > Page: https://www.postgresql.org/docs/13/plpgsql-statements.html > Description: > > Hey Kind Doc People > I was hoping we could add sub-anchors for each of the sections on this page. > It would make it easier to link to the specific content of

Re: Document "59.2. Built-in Operator Classes" have a clerical error?

On 2020-Aug-27, Michael Paquier wrote: > This leads me to the updated version attached. BRIN has 29 different > opclasses, visibly. I checked both HTML and PDF and it looks good to me to commit. As a subsequent improvement we could discuss tweak the stylesheets to change the column widths in

Re: Document "59.2. Built-in Operator Classes" have a clerical error?

On 2020-Aug-26, Bruce Momjian wrote: > On Wed, Aug 26, 2020 at 05:58:01PM -0400, Alvaro Herrera wrote: > > Well, there is a small problem here ... which is that I misled you with > > \dAo ... because that one lists the operators for the opfamilies, not > > for the opclasse

Re: Document "59.2. Built-in Operator Classes" have a clerical error?

On 2020-Aug-26, Michael Paquier wrote: > On Tue, Aug 25, 2020 at 06:17:28PM -0400, Tom Lane wrote: > > I wonder if it would look better if we suppress the horizontal rules > > between the operator names within a cell. IIRC, it's possible to do > > that, though the exact incantation isn't coming

Re: Document "59.2. Built-in Operator Classes" have a clerical error?

On 2020-Aug-25, Michael Paquier wrote: > I think so. If there are other places, it does not prevent improving > what we already know needs improvement. > > FWIW, the layout I was thinking about is something like the patch > attached. This looks to me enough of an improvement that I +1 it, and

Re: Document "59.2. Built-in Operator Classes" have a clerical error?

On 2020-Aug-24, Bruce Momjian wrote: > I don't think it is worth it, plus we would need to adjust the docs if > system catalog layout changes. I think we just want something concise > and simple, but also accurate. I argued for \dAo, not straight catalog output -- that was a straw man. I can't

Re: Document "59.2. Built-in Operator Classes" have a clerical error?

On 2020-Aug-22, Tom Lane wrote: > If you don't want to go all the way and list the operators with their > input types, maybe we should just do what the OP thought was correct > and delete the duplicate operator names. It's already the case that > the table isn't telling you exactly which input

Re: Document "59.2. Built-in Operator Classes" have a clerical error?

On 2020-Aug-21, Bruce Momjian wrote: > On Mon, Aug 3, 2020 at 04:49:04PM +0900, Michael Paquier wrote: > > On Mon, Aug 03, 2020 at 03:14:56PM +0800, osdba wrote: > > > "range_opsany range type&& &> &< >> << <@ -|- = @> @>"， exist double "@>"， > > > > > > Should be "<@ @>" ? > > > > Indeed,

Re: [DOCS] Let's document a bytea bug

On 2020-Aug-03, Bruce Momjian wrote: > So, the character and octet length is 600 million, but on output, that > will be expanded, and both SELECT and pg_dump fail. I also can't see > how to improve the error message since it happens so low in the stack. I think you'll find commits fa2fa9955280

Re: Add A Glossary

On 2020-Jul-21, Jürgen Purtz wrote: > - Added '(process)' to the two terms 'Autovacuum' and 'Stats Collector' > > - Removed link to himself in 'Logger (process)' > > - new term: Base Backup Pushed. I was not courageous enough to include "base backup" in 13, so that one's in master only, but

Re: Please add a link to [BRIN] physical block ranges of a table

On 2020-Jun-25, Steven Pousty wrote: > I like the direction as well as long as each of the items in the glossary > has an anchor and you can link to it from the rest of the documents. It has. > The reader, if they are confused by the term, should be able to go get > a quick definition without

Re: Please add a link to [BRIN] physical block ranges of a table

We have a glossary page as of Postgres 13[1]; since it's new, links to it have not yet percolated to the rest of the docs, but that should start happening in the pg14 cycle. You're welcome to submit a patch that adds the term you want to link as well as a patch that turns the text you want into a

Re: The description for pg_replication_slots.restart_lsn

On 2020-Jun-17, Fujii Masao wrote: > The document explains that restart_lsn column in pg_replication_slots view is: > > The address (LSN) of oldest WAL which still might be required by > the consumer of this slot and thus won't be automatically removed > during checkpoints. > > But

Re: Summary of DDL/DML statement return/output values?

On 2020-Jun-23, Steve Estes wrote: > Thanks Alvaro. Looks cool. So, on the one hand it'd be nice to be able to > auto-generate this once all the commands are standardized into one > structure. That'd be slick. I thought they were already standardized ... But anyway, I was thinking that this

Re: Summary of DDL/DML statement return/output values?

On 2020-Jun-22, Steve Estes wrote: > However, for some statements PG's output format is documented (e.g. INSERT > , EXPLAIN > ), and in others it is > not (e.g. SET

Re: Add A Glossary

Thanks for these fixes! I included all of these. On 2020-Jun-19, Erik Rijkers wrote: > And one thing that I am not sure of (but strikes me as a bit odd): > there are several cases of > 'are enforced unique'. Should that not be > 'are enforced to be unique' ? I included this change too; I am

Re: Add A Glossary

On 2020-Jun-16, Justin Pryzby wrote: > On Tue, Jun 16, 2020 at 08:09:26PM -0400, Alvaro Herrera wrote: Thanks for the review. I merged all your suggestions. This one: > >Most local objects belong to a specific > > + schema in their > > +

Re: Add A Glossary

On 2020-Jun-09, Jürgen Purtz wrote: > Can you agree to the following definitions? If no, we can alternatively > formulate for each of them: "Under discussion - currently not defined". My > proposals are inspired by chapter 2.2 Concepts: "Tables are grouped into > databases, and a collection of

Re: some charts or graphs of possible permissions would be nice

On 2020-Jun-10, Laurenz Albe wrote: > On Tue, 2020-06-09 at 21:34 +, PG Doc comments form wrote: > > Having read through the documentation on roles/granting I think I more or > > less understand how it works, but what isn't really clarified is what the > > overall universe of permissions that

Re: Adding xreflable

On 2020-Jun-02, Bruce Momjian wrote: > I can adjust things, but what logic are we following? Before my patch, > sepgsql had an xreflabel, and vacuumlo did not. I would like to have a > documented policy of where we should have xreflabels, and where not, and > I can then adjust things to match.

Re: ATTACH/DETACH partitions and locking

On 2019-Jun-14, Pavel Luzanov wrote: > Does it make sense to change this way? > "Some operations require a stronger lock when using declarative partitioning > than when using table inheritance. For example, removing a > partition from a partitioned table requires taking an ACCESS EXCLUSIVE > lock

Re: Another modest proposal for docs formatting: catalog descriptions

On 2020-May-06, Alvaro Herrera wrote: > ... oh, okay. I guess I was reporting that the font on the new version > seems to have got smaller. Looking at other pages, it appears that the > font is indeed a lot smaller in all tables, including those Tom has been > editin

Re: non-string or non-string

On 2020-May-17, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/11/functions-string.html > Description: > > The second line in "Table 9.8. SQL String Functions and Operators" uses > "non-string or

Re: Logical replication subscription owner

On 2020-May-07, Tom Lane wrote: > FWIW, I would argue that LOGIN permits logging in on a regular SQL > connection, while REPLICATION should permit logging in on a > replication connection, and there's no reason for either to depend on > or require the other. I agree with this. > >> Also- what

Re: Logical replication subscription owner

I'd welcome input from other people on this issue; only now I noticed that it's buried in pgsql-docs, so CCing pgsql-hackers now. On 2020-Apr-23, Stephen Frost wrote: > Greetings, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Alvaro Herrera writes: > > > I had

Re: Another modest proposal for docs formatting: catalog descriptions

On 2020-May-06, Jonathan S. Katz wrote: > I know that 9.6 uses a different subset of the styles, and I recall the > text being blue during the original conversion. For example, the "table" > in the 9.6 docs has a class of "CALSTABLE" whereas in master, it is > "table" (and we operate off of it as

Re: Rendering pi more nicely in PDF

On 2020-Apr-29, Peter Eisentraut wrote: > To use a different font, you have to (a) pick one, and (b) install it > locally when you build the PDFs. > > My proposal is to use the DejaVu fonts, which are open source and easily > available for common operating systems. (Arguably, they also give the

  1   2   >