Re: Add small detail to RAISE statement descripton

On Wed, May 22, 2024 at 11:35 PM Igor Gnatyuk wrote: > > Hi, > > thanks for the response and for your corrections to the patch. > But I checked my changes by running make html, make postgres-A4.pdf, > make postgres-US.pdf and viewing > the results: everything is OK. > > Message > 'old mode 100644

ltree docs imprecise about sorting order

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/ltree.html Description: The ltree docs available at https://www.postgresql.org/docs/current/ltree.html state "Comparison sorts in the order of a tree traversal" without specifying the

Re: column_name of ALTER MATERIALIZED VIEW should only refer to an existing column

On 2024-05-23 06:04 +0200, Michael Paquier wrote: > On Wed, May 22, 2024 at 02:12:36PM +0900, Michael Paquier wrote: > > Will fix once we are out of release freeze time on HEAD. Thanks! > > And done as of dd087e1c13bf. Thank you Michael! -- Erik

Building from source using clean Ubuntu docker container

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/install-make.html Description: Hello there, Below are complete steps for building Postgres from source in a clean docker ubuntu container. Maybe this is useful for your docs? I noticed

Re: column_name of ALTER MATERIALIZED VIEW should only refer to an existing column

On Wed, May 22, 2024 at 02:12:36PM +0900, Michael Paquier wrote: > Will fix once we are out of release freeze time on HEAD. Thanks! And done as of dd087e1c13bf. -- Michael signature.asc Description: PGP signature

Re: Add small detail to RAISE statement descripton

Hi, thanks for the response and for your corrections to the patch. But I checked my changes by running make html, make postgres-A4.pdf, make postgres-US.pdf and viewing the results: everything is OK. Message 'old mode 100644 new mode 100755' this means, imho, that access rights were changed

Re: Add small detail to RAISE statement descripton

On Wed, May 22, 2024 at 4:18 PM Igor Gnatyuk wrote: > > Hi. > > Thanks for the comments. I fixed my mistakes by specifying sqlcode > instead of sqlstate and changed the phrase > with an explicit listing of options in USING. In addition, I moved the > paragraph with it below. > Please check out

Re: Ambiguous description on new columns

On Tue, May 21, 2024 at 8:40 PM PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/logical-replication-col-lists.html > Description: > > The documentation on this page mentions: > > "If no column list is

Re: Add small detail to RAISE statement descripton

Hi. Thanks for the comments. I fixed my mistakes by specifying sqlcode instead of sqlstate and changed the phrase with an explicit listing of options in USING. In addition, I moved the paragraph with it below. Please check out the new patch version in the attachment. Regards, Igor Gnatyuk вс,

Re: Ambiguous description on new columns

On Wed, 2024-05-22 at 12:47 +1000, Peter Smith wrote: > I think the following small change will remove any ambiguity: > > BEFORE > If no column list is specified, any columns added later are > automatically replicated. > > SUGGESTION > If no column list is specified, any columns added to the

Re: column_name of ALTER MATERIALIZED VIEW should only refer to an existing column

On Wed, May 22, 2024 at 02:59:37AM +0200, Erik Wienhold wrote: > Here's a patch for $SUBJECT. Looks like the current wording was copied > from ALTER TABLE. In ALTER VIEW we correctly state that column_name > must be an existing column. Fun. You are right, none of the patterns supported by this

Re: Ambiguous description on new columns

On Tuesday, May 21, 2024, Peter Smith wrote: > > > > > Each publication can optionally specify which columns of each table are > replicated to subscribers. The table on the subscriber side must have at > least all the columns that are published. If no column list is specified, > then all columns

Re: Ambiguous description on new columns

On Wed, May 22, 2024 at 1:22 PM David G. Johnston wrote: > > On Tue, May 21, 2024 at 7:48 PM Peter Smith wrote: >> >> >> I think the following small change will remove any ambiguity: >> >> BEFORE >> If no column list is specified, any columns added later are >> automatically replicated. >> >>

Re: Ambiguous description on new columns

On Tue, May 21, 2024 at 7:48 PM Peter Smith wrote: > > I think the following small change will remove any ambiguity: > > BEFORE > If no column list is specified, any columns added later are > automatically replicated. > > SUGGESTION > If no column list is specified, any columns added to the

Re: Ambiguous description on new columns

On Tue, May 21, 2024 at 3:40 AM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: > https://www.postgresql.org/docs/16/logical-replication-col-lists.html > Description: > > The documentation on this page mentions: > > "If no column list

Re: Ambiguous description on new columns

On Tue, May 21, 2024 at 8:40 PM PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/logical-replication-col-lists.html > Description: > > The documentation on this page mentions: > > "If no column list is

column_name of ALTER MATERIALIZED VIEW should only refer to an existing column

Here's a patch for $SUBJECT. Looks like the current wording was copied from ALTER TABLE. In ALTER VIEW we correctly state that column_name must be an existing column. -- Erik >From 1d7accf2311f4fda2d8ef9a0485985620c5b4b39 Mon Sep 17 00:00:00 2001 From: Erik Wienhold Date: Wed, 22 May 2024

Re: Ambiguous description on new columns

Hi, Le mar. 21 mai 2024 à 12:40, PG Doc comments form a écrit : > The following documentation comment has been logged on the website: > > Page: > https://www.postgresql.org/docs/16/logical-replication-col-lists.html > Description: > > The documentation on this page mentions: > > "If no column

Re: 52.38 pg_proc (postgresql version 14)

On Mon, 2024-05-20 at 21:07 +, PG Doc comments form wrote: > Page: https://www.postgresql.org/docs/14/catalog-pg-proc.html > Description: > > I don't know if this is a documentation problem or an error in pg_proc. > > The document, for the "prokind" column state the following: > f for

Ambiguous description on new columns

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/logical-replication-col-lists.html Description: The documentation on this page mentions: "If no column list is specified, any columns added later are automatically replicated." It feels

52.38 pg_proc (postgresql version 14)

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/catalog-pg-proc.html Description: I don't know if this is a documentation problem or an error in pg_proc. The document, for the "prokind" column state the following: f for a

Fundamental Architecture of PostgreSQL

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/tutorial-arch.html Description: PostgreSQL uses a client/server architecture. As is typical of client/server applications, the client and the server can be on different hosts. In that

Re: Unclear on Publication documentation page

On Sat, May 18, 2024, at 5:44 PM, PG Doc comments form wrote: > The page in question: > https://www.postgresql.org/docs/current/logical-replication-publication.html > > It says: > > "If a table without a replica identity is added to a publication that > replicates UPDATE or DELETE operations

Logical replication - initial data synchronization

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/logical-replication-subscription.html Description: I'm reading up on Logical Replication and have been reading the pages in order. The first 2 pages:

Unclear on Publication documentation page

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/logical-replication-publication.html Description: The page in question: https://www.postgresql.org/docs/current/logical-replication-publication.html It says: "If a table without a

Re: Add small detail to RAISE statement descripton

On Fri, May 17, 2024 at 4:39 PM Igor Gnatyuk wrote: > > Hi. > > Thank you for your letter. I tried to take your comments into account: > I added explanations to the condition_name, sqlstate options and > slightly changed > the explanations for USING. Attached you will find new patch version. >

Re: Add small detail to RAISE statement descripton

Hi. Thank you for your letter. I tried to take your comments into account: I added explanations to the condition_name, sqlstate options and slightly changed the explanations for USING. Attached you will find new patch version. Thank you for your help. Ragards, Igor Gnatyuk ср, 15 мая 2024 г. в

Re: Add small detail to RAISE statement descripton

On Tue, May 14, 2024 at 11:09 PM Igor Gnatyuk wrote: > > Hi, > > There is a slight syntax inaccuracy in the description of the RAISE > statement - assignments of parameter values in USING. > (Chapter 43. PL/pgSQL — SQL Procedural Language / 43.9 Errors and > Messages / 43.9.1 Reporting Errors and

Add small detail to RAISE statement descripton

Hi, There is a slight syntax inaccuracy in the description of the RAISE statement - assignments of parameter values in USING. (Chapter 43. PL/pgSQL — SQL Procedural Language / 43.9 Errors and Messages / 43.9.1 Reporting Errors and Messages): "...You can attach additional information to the error

Re: Explanations not clear

On 13.05.24 21:10, Jeff Davis wrote: On Wed, 2024-05-08 at 08:52 +0200, Peter Eisentraut wrote: I created a collation specifying the ks-level3 setting and with deterministic set to false. But when I compare "a_b" to "a-b" with this collation I get false. According to the table 24.1 it should

Re: roles that have the CREATEROLE privilege can no longer GRANT predefined roles

On Thu, May 2, 2024 at 3:36 AM Laurenz Albe wrote: > On Wed, 2024-05-01 at 16:09 +, PG Doc comments form wrote: > > Page: https://www.postgresql.org/docs/16/predefined-roles.html > > > > roles that have the CREATEROLE privilege can no longer GRANT predefined > > roles unless they are part of

Re: Explanations not clear

On Wed, 2024-05-08 at 08:52 +0200, Peter Eisentraut wrote: > > I created a collation specifying the ks-level3 setting and with > > deterministic set to false. But when I compare "a_b" to "a-b" with > > this > > collation I get false. According to the table 24.1 it should yield > > true. > > Only

Re: Explanations not clear

On 06.05.24 19:59, PG Doc comments form wrote: The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/collation.html Description: I created a collation specifying the ks-level3 setting and with deterministic set to false. But when I compare

Explanations not clear

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/collation.html Description: I created a collation specifying the ks-level3 setting and with deterministic set to false. But when I compare "a_b" to "a-b" with this collation I get false.

Re: Connection Info

On Sun, 2024-05-05 at 20:25 +, PG Doc comments form wrote: > On this page: > https://www.postgresql.org/docs/14/server-start.html#CLIENT-CONNECTION-PROBLEMS > > It notes: " A common mistake is to forget to configure the server to > allow TCP/IP connections." > > I would expect a

Re: nchar is undocumented

On 2024-05-06 10:59 +0200, Alvaro Herrera wrote: > 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." > ? Yeah,

Connection Info

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/server-start.html Description: Hello! On this page: https://www.postgresql.org/docs/14/server-start.html#CLIENT-CONNECTION-PROBLEMS It notes: " A common mistake is to forget to

Re: nchar is undocumented

On 06.05.24 10:53, Alvaro Herrera wrote: 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.

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: Missing examples for hash partitioning

On Sun, 5 May 2024 at 19:27, David Rowley wrote: > There are examples of hash partitioning in [1]. Maybe we should add a > link so those can be more easily found. I see the link is already there, per: "See CREATE TABLE for more details on creating partitioned tables and partitions." David >

Re: Missing examples for hash partitioning

On Sun, 5 May 2024 at 08:13, PG Doc comments form wrote: > Page: https://www.postgresql.org/docs/16/ddl-partitioning.html > Description: > > There is no example showing the syntax of Hash Partitioning in this section > of the documentation, it's missing. There are examples of hash partitioning

Re: nchar is undocumented

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 former, that way we don't need to reconsider Peter's

nchar is undocumented

While studying the parser, I noticed that we support nchar and the n'' literal. But both concepts are undocumented. That may be intentional because nchar is just an alias for char and because all our string types are multibyte and therefore essentially national character strings. I was looking

Missing examples for hash partitioning

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/ddl-partitioning.html Description: There is no example showing the syntax of Hash Partitioning in this section of the documentation, it's missing.

Re: RETURNING order guarantees documentation

"David G. Johnston" writes: > On Sat, May 4, 2024, 10:13 Dan Wainwright wrote: >> 'Similar to' doesn't provide anything concrete to the reader. There was a >> thread >> on [Hackers] >> >> back in 2015 proposing some docs

Re: RETURNING order guarantees documentation

On Sat, May 4, 2024, 10:13 Dan Wainwright wrote: > > 'Similar to' doesn't provide anything concrete to the reader. There was a > thread > on [Hackers] > > back in 2015 proposing some docs to clearly explain that ordering

RETURNING order guarantees documentation

Hi, I was looking for documentation on the ordering guarantees of RETURNING statements relative to the input data and found that there is nothing explicit. The insert docs state > If the INSERT command contains a RETURNING clause, the result will be similar to that of a SELECT statement

Re: The PostgreSQL Select Syntax

On 02.05.24 20:08, PG Doc comments form wrote: I'm writing to seek clarification regarding the scope of the formal syntax outlined in the documentation for the SELECT statement (https://www.postgresql.org/account/comments/new/16/sql-select.html/). I understand that this syntax defines the core

The PostgreSQL Select Syntax

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/sql-select.html Description: Dear PostgreSQL Team, I'm writing to seek clarification regarding the scope of the formal syntax outlined in the documentation for the SELECT statement

Re: roles that have the CREATEROLE privilege can no longer GRANT predefined roles

On Wed, 2024-05-01 at 16:09 +, PG Doc comments form wrote: > Page: https://www.postgresql.org/docs/16/predefined-roles.html > > roles that have the CREATEROLE privilege can no longer GRANT predefined > roles unless they are part of it having the WITH ADMIN option. this needs to > be corrected

roles that have the CREATEROLE privilege can no longer GRANT predefined roles

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/predefined-roles.html Description: roles that have the CREATEROLE privilege can no longer GRANT predefined roles unless they are part of it having the WITH ADMIN option. this needs to be

Re: nested tags in glossary entries in html docs

On 2024-04-25 22:00 +0200, Alexander Lakhin wrote: > 25.04.2024 12:24, Alvaro Herrera wrote: > > 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

Re: nested tags in glossary entries in html docs

Hello, 25.04.2024 12:24, Alvaro Herrera wrote: 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

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-04-25 15:40 +0200, Jürgen Purtz wrote: > On 25.04.24 13:24, Jürgen Purtz wrote: > > > > On 25.04.24 11:24, Alvaro Herrera wrote: > > > 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

Re: nested tags in glossary entries in html docs

On 25.04.24 13:24, Jürgen Purtz wrote: On 25.04.24 11:24, Alvaro Herrera wrote: 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

Re: nested tags in glossary entries in html docs

On 25.04.24 11:24, Alvaro Herrera wrote: 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

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: The prompt is not displayed correctly in the example on psql page

> On 22 Apr 2024, at 10:45, Daniel Gustafsson wrote: > >> On 21 Apr 2024, at 12:57, PG Doc comments form >> wrote: >> >> The following documentation comment has been logged on the website: >> >> Page: https://www.postgresql.org/docs/16/app-psql.html >> Description: >> >> On this page

Re: wal_init_zero / wal_recycle

On Wednesday, April 24th, 2024 at 10:57, Peter Eisentraut wrote: > It currently says: > > wal_init_zero: "... causes new WAL files to be filled with zeroes ..." > > wal_recycle: "... avoiding the need to create new ones ..." > > I'm not sure where exactly to make that more clear.

Re: wal_init_zero / wal_recycle

On 24.04.24 10:08, Nicolas Seinlet wrote: while searching the doc to solve an issue, I found the interdependency between those 2 parameters was not obvious. Here: https://www.postgresql.org/docs/14/runtime-config-wal.html#GUC-WAL-INIT-ZERO

wal_init_zero / wal_recycle

Hello, while searching the doc to solve an issue, I found the interdependency between those 2 parameters was not obvious. Here: https://www.postgresql.org/docs/14/runtime-config-wal.html#GUC-WAL-INIT-ZERO the wal_init_zero set to ON cause new WAL files to be filled with zeroes. It was not

Re: No documentation on how pg_ctl is installed

On 23.04.24 14:40, PG Doc comments form wrote: The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/15/app-pg-ctl.html Description: I have used postgresql@14 for several years and have always used pg_ctl to start the postgres server, check

Re: No documentation on how pg_ctl is installed

Daniel Gustafsson writes: >> On 23 Apr 2024, at 14:40, PG Doc comments form >> wrote: >> I tried upgrading to postgresql@15 with the command brew install >> postgresql@15 on a Mac from Terminal and pg_ctl is apparently not installed. > This sounds like a question for the Homebrew maintainers,

Re: No documentation on how pg_ctl is installed

> On 23 Apr 2024, at 14:40, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/15/app-pg-ctl.html > Description: > > I have used postgresql@14 for several years and have always used pg_ctl to > start the

No documentation on how pg_ctl is installed

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/15/app-pg-ctl.html Description: I have used postgresql@14 for several years and have always used pg_ctl to start the postgres server, check status etc. I tried upgrading to postgresql@15

Re: Documentation Chapter 16: 8.21

Erik Wienhold writes: > On 2024-04-20 14:22 +0200, PG Doc comments form wrote: >> I tryed to implement a safe_cast function with 2 parameters and a return of >> type "any" but it failed. >> And if there is a data type "any" in postgres too, how should it work as >> parameter and wheres the

Re: Documentation Chapter 16: 8.21

On 2024-04-20 14:22 +0200, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/datatype-pseudo.html > Description: > > I tryed to implement a safe_cast function with 2 parameters and a return of > type

Re: The prompt is not displayed correctly in the example on psql page

> On 21 Apr 2024, at 12:57, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/app-psql.html > Description: > > On this page https://www.postgresql.org/docs/current/app-psql.html > > where is? >> `(

Documentation Chapter 16: 8.21

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/datatype-pseudo.html Description: I tryed to implement a safe_cast function with 2 parameters and a return of type "any" but it failed. I get a syntax error, if I use "any" as a data

The prompt is not displayed correctly in the example on psql page

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/app-psql.html Description: On this page https://www.postgresql.org/docs/current/app-psql.html where is? >> `( if there is an unmatched left parenthesis` ```sql testdb=> SELECT t1.first

Re: pg_createsubscriber: A more precise link to the initial data sync

> On 16 Apr 2024, at 12:42, Pavel Luzanov wrote: > > Please consider a small correction of the link to the initial data > synchronization section on the pg_createsubscriber page. Agreed, that makes sense. Applied. -- Daniel Gustafsson

Re: Update Help on PREPARE to mention DEALLOCATE

On Tue, Apr 16, 2024 at 4:42 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Tue, Apr 16, 2024 at 1:27 PM Kirk Wolak wrote: > >> Could we make the PREPARE line read >> ... >> > No. That is a syntax excerpt and the prepare command doesn't accept an > optional deallocate keyword at

Re: Update Help on PREPARE to mention DEALLOCATE

On Tue, Apr 16, 2024 at 1:27 PM Kirk Wolak wrote: > Could we make the PREPARE line read > > PREPARE [ DEALLOCATE ] ...? > > So it's more consistent, and the user using a PREPARE gets a clue to > DEALLOCATE? > > No. That is a syntax excerpt and the prepare command doesn't accept an optional

Update Help on PREPARE to mention DEALLOCATE

Please notice this exchange: 16:20:02 devuser@nctest= # \h deallocate Command: DEALLOCATE Description: deallocate a prepared statement Syntax: DEALLOCATE [ PREPARE ] { name | ALL } URL: https://www.postgresql.org/docs/16/sql-deallocate.html 16:20:11 devuser@nctest= # \h PREPARE Command:

pg_createsubscriber: A more precise link to the initial data sync

Please consider a small correction of the link to the initial data synchronization section on the pg_createsubscriber page. -- Pavel Luzanov Postgres Professional:https://postgrespro.com From d040324464d5ef4cefd63e4d34373a90e2496b57 Mon Sep 17 00:00:00 2001 From: Pavel Luzanov Date: Tue, 16

Re: three small improvements for "Composite Types" page

On 12/04/2024 23:44, David G. Johnston wrote: I'd much prefer to leave "different kind" alone and turn the immediately following, first-on-the-page, instance of CREATE TYPE into a link. Good, I'm fine with that too.  2. make first mention of CREATE TABLE a link [...] > I'm not all that

Re: CREATE ROLE inheritance details

On Wed, Apr 03, 2024 at 06:11:47PM -0700, David G. Johnston wrote: > On Sat, Mar 30, 2024 at 11:16 PM Noah Misch wrote: > > On Tue, Jan 30, 2024 at 01:49:42PM -0700, David G. Johnston wrote: > > > + The membership grants created by the > > > + IN ROLE, ROLE, and > > ADMIN > > > + clauses

Re: three small improvements for "Composite Types" page

On Fri, Apr 12, 2024 at 1:20 PM Anton Voloshin wrote: > Hello, > > While reading "Composite Types" manual page I've noticed that it is > somewhat hard to follow by trying out given examples. I suggest three > small changes which would make this page a little easier to follow for > me: > > 1.

three small improvements for "Composite Types" page

Hello, While reading "Composite Types" manual page I've noticed that it is somewhat hard to follow by trying out given examples. I suggest three small changes which would make this page a little easier to follow for me: 1. Clarify "different kind" by adding a link to a section of "create type"

Re: nested tags in glossary entries in html docs

On 2024-04-12 18:29 +0200, Anton Voloshin wrote: > In REL_13_STABLE and above, generated HTML have a broken HTML: nested href="..."> tags for all links to glossary. Somehow, this results in > duplicated tags on the https://www.postgresql.org/docs/ > > Found by tab-navigating

nested tags in glossary entries in html docs

Hello, In REL_13_STABLE and above, generated HTML have a broken HTML: nested href="..."> tags for all links to glossary. Somehow, this results in duplicated tags on the https://www.postgresql.org/docs/ Found by tab-navigating https://www.postgresql.org/docs/16/rowtypes.html where we see

Re: Mysteries of the future

"David G. Johnston" writes: > The request is to fix our documentation to use a valid date for the example > in the paragraph that describes the separator requirement for years greater > than 4 digits. Oh! Got it, that should be fixed. regards, tom lane

Re: Mysteries of the future

On Thu, Apr 11, 2024 at 7:20 AM Tom Lane wrote: > PG Doc comments form writes: > > SELECT to_date('2-1131', '-MMDD'); > > ERROR: 22008: date/time field value out of range: "2-1131" > > What exactly do you find wrong with that? November doesn't have > 31 days. > > Sure, we could

Re: Mysteries of the future

PG Doc comments form writes: > SELECT to_date('2-1131', '-MMDD'); > ERROR: 22008: date/time field value out of range: "2-1131" What exactly do you find wrong with that? November doesn't have 31 days. Sure, we could have a discussion about the probability of the Gregorian calendar

Postgres_FDW doc doesn't specify TYPE support in Remote Execution Options

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/postgres-fdw.html Description: Hi, The https://www.postgresql.org/docs/current/postgres-fdw.html#POSTGRES-FDW-OPTIONS-REMOTE-EXECUTION section mentions for `extensions` configuration

Re: Postgres_FDW doc doesn't specify TYPE support in Remote Execution Options

Hi, please ignore my last email about the patch. :/ I have determined that pushdown of custom data types through fdw in fact does make sense. Consider this query: SELECT * FROM customers WHERE ; To push down the WHERE clause to the foreign servers, both local and foreign server must have the

Mysteries of the future

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/functions-formatting.html Description: I'm not sure that there will be 31 days in 11 months; although postgresql probably knows better what will happen in 2 For example (with the

Re: tools.ietf.org is decommissioned and our links are redirected

> On 4 Apr 2024, at 12:41, Daniel Gustafsson wrote: > >> On 3 Apr 2024, at 14:23, Magnus Hagander wrote: >> >> On Wed, Apr 3, 2024 at 1:18 PM Daniel Gustafsson > > wrote: >> The tools.ietf.org server which we use for all >> RFC/BCP links in the

Re: 8.14.5 jsonb subscripting

Thank you all for super prompt and friendly support. Best regards Arne tir. 9. apr. 2024 kl. 16:26 skrev Tom Lane : > Arne Sommerfelt writes: > > Thank you! When googling it is easy to end up with latest docs, > > unfortunately > > That's actually good news --- it used to be that Google would

Re: psql option

On Wed, Apr 10, 2024 at 12:01:39AM +0200, Daniel Gustafsson wrote: > > On 9 Apr 2024, at 18:33, Daniel Gustafsson wrote: > > > >> On 9 Apr 2024, at 16:05, PG Doc comments form > >> wrote: > >> > >> The following documentation comment has been logged on the website: > >> > >> Page:

Re: psql option

> On 9 Apr 2024, at 18:33, Daniel Gustafsson wrote: > >> On 9 Apr 2024, at 16:05, PG Doc comments form wrote: >> >> The following documentation comment has been logged on the website: >> >> Page: https://www.postgresql.org/docs/16/app-psql.html >> Description: >> >> option -X, >> >> the

Re: psql option

> On 9 Apr 2024, at 16:05, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/app-psql.html > Description: > > option -X, > > the specified comma after the letter X > >

psql option

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/app-psql.html Description: option -X, the specified comma after the letter X https://www.postgresql.org/docs/current/app-psql.html

Re: Postgres_FDW doc doesn't specify TYPE support in Remote Execution Options

Hi team . In the https://www.postgresql.org/docs/current/postgres-fdw.html#POSTGRES-FDW-OPTIONS-REMOTE-EXECUTION doc, it mentions that Immutable Functions and Hi can be pushed down using `extensions` option for foreign server. But it does not mention TYPE. In the shippable.c

Re: 8.14.5 jsonb subscripting

Arne Sommerfelt writes: > Thank you! When googling it is easy to end up with latest docs, > unfortunately That's actually good news --- it used to be that Google would tend to steer people to very ancient versions of our docs. Sounds like the SEO work that we've done is paying off. However, if

Re: 8.14.5 jsonb subscripting

On Tuesday, April 9, 2024, Arne Sommerfelt wrote: > Thank you! When googling it is easy to end up with latest docs, > unfortunately > The 12 is a hyperlink so it is almost just as easy to view the current page in the prior version. David J.

Re: 8.14.5 jsonb subscripting

Thank you! When googling it is easy to end up with latest docs, unfortunately Arne tir. 9. apr. 2024 kl. 16:06 skrev Daniel Gustafsson : > > On 9 Apr 2024, at 16:04, Arne Sommerfelt > wrote: > > > > 12 is in the list of supported versions at the top of chapter 8.14. And > the non-working

  1   2   3   4   5   6   7   8   9   10   >