Re: 1.3 Creating a database - windows 10x64

2023-02-02 Thread Erik Wienhold
> On 02/02/2023 01:52 CET PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/15/tutorial-createdb.html > Description: > > I installed pgsql with binary for windows from official website. > Going through the

Re: Publishing Postgres Manual as a book

2023-03-22 Thread Erik Wienhold
> On 23/03/2023 02:35 CET Siddharth Jain wrote: > > The Postgres Manual is available online as a PDF but I think having it in a > book form could be useful to some. > > Is it legal for me to publish the manual as a book? IANAL, but I'd say yes as long as you don't take a fee. The legal notice of

Re: Publishing Postgres Manual as a book

2023-03-22 Thread Erik Wienhold
> On 23/03/2023 04:34 CET Ian Lawrence Barwick wrote: > > 2023年3月23日(木) 12:23 Erik Wienhold : > > > > > On 23/03/2023 02:35 CET Siddharth Jain wrote: > > > > > > The Postgres Manual is available online as a PDF but I think having it in >

Re: Split_Part w/negative integer does not work

2023-03-25 Thread Erik Wienhold
> On 24/03/2023 21:45 CET PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/15/functions-string.html > Description: > > When n is negative, an error occurs. > > Documentation > split_part ( string text, del

Re: Correction: Postgres emum documentation 8.7.4 should read 63 characters (instead of bytes)

2023-04-02 Thread Erik Wienhold
> On 01/04/2023 00:17 CEST PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/15/datatype-enum.html > Description: > > Postgres documentation, section 8.7.4 gives the limit on enum labels as 63 > bytes. > Te

Re: Cross-Product JOIN?

2023-05-24 Thread Erik Wienhold
> On 24/05/2023 10:22 CEST Atomic_Sheep wrote: > > "Finally, NATURAL is a shorthand form of USING: it forms a USING list > consisting of all column > names that appear in both input tables. As with USING, these columns > appear only once in the > output table. If there are no common column names,

Re: Cross-Product JOIN?

2023-05-24 Thread Erik Wienhold
> On 24/05/2023 15:46 CEST Erik Wienhold wrote: > > Personally, I think it should read cartesian product because cross product is > an overloaded term and cartesian product is used more often in the > documentation > overall. > > But the same page [0] also uses cross pr

Re: Cross-Product JOIN?

2023-05-25 Thread Erik Wienhold
> On 25/05/2023 06:52 CEST Laurenz Albe wrote: > > On Wed, 2023-05-24 at 21:10 +0200, Erik Wienhold wrote: > > > On 24/05/2023 15:46 CEST Erik Wienhold wrote: > > > > > > Personally, I think it should read cartesian product because cross > > > prod

Re: Cross-Product JOIN?

2023-05-25 Thread Erik Wienhold
> On 25/05/2023 23:46 CEST Laurenz Albe wrote: > > On Thu, 2023-05-25 at 08:59 +0200, Erik Wienhold wrote: > > > Since we are talking about Cartesian products: is the term "Cartesian > > > join" > > > used anywhere? > > > > Not in the doc

Re: 5.11.1 Table Partitioning Overview - "...the size of the table should exceed the physical memory.."

2023-05-30 Thread Erik Wienhold
> On 30/05/2023 07:06 CEST PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/15/ddl-partitioning.html > Description: > > Is this rule of thumb a typo? > > "The exact point at which a table will benefit from

Re: pg data type bool is the boolean ,but in the documents there is no description about " bool is equal to boolean”

2023-06-04 Thread Erik Wienhold
> On 04/06/2023 17:04 CEST yanliang lei wrote: > > bool datatype is equal to boolean datatyp, but the documents > (https://www.postgresql.org/docs/15/datatype-boolean.html) there is no > description about " bool dataype is equal to boolean datatype ” The type aliases are listed in table 8.1: http

Re: Further clarification in documentation: No deletion of unreferenced large objects

2023-06-12 Thread Erik Wienhold
> On 12/06/2023 15:48 CEST PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/15/datatype-binary.html > Description: > > When deleting a row that references (contains) a large object, I think that > most use

Re: large scale reliable software system

2023-06-21 Thread Erik Wienhold
I recommend posting this to pgsql-admin or pgsql-general instead of pgsql-docs to get more responses. Besides that, pgsql-docs is for discussions on the Postgres docs. > On 21/06/2023 18:52 CEST B M wrote: > > I would like to know your advices to develop a large scale reliable software > system

Re: Change "two" to "three" for decades of development in history

2023-06-22 Thread Erik Wienhold
> On 22/06/2023 23:00 CEST Bruce Momjian wrote: > > On Thu, Jun 22, 2023 at 01:47:16PM -0700, Kirk Parker wrote: > > > > I don't suppose DocBook has macro and system-variable capabilities? That > > could provide a set-and-forget solution to this? > > Uh, I am not aware of any. An SGML entity [0]

Re: Wrong statement on the materialized views page

2023-08-21 Thread Erik Wienhold
> On 21/08/2023 09:02 CEST PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/15/rules-materializedviews.html > Description: > > There might be an issue on this page: > https://www.postgresql.org/docs/curren

Re: CREATE TRIGGER documentation inconsistensies

2023-08-24 Thread Erik Wienhold
> On 24/08/2023 09:50 CEST PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/14/sql-createtrigger.html > Description: > > In PostgreSQL 14 and 15 (previous versions I've not checked) is stated that > CREATE

Re: Error in Example

2023-09-01 Thread Erik Wienhold
On 31/08/2023 01:29 CEST PG Doc comments form wrote: > Page: https://www.postgresql.org/docs/15/indexes-partial.html > Description: > > The IP addresses used to exemplify which one will be covered by the partial > index are inverted. No, the example is correct. It's about only indexing addresse

Re: Unclear guarantees about sort order on https://www.postgresql.org/docs/current/queries-order.html

2023-10-04 Thread Erik Wienhold
On 2023-10-04 16:24 +0200, PG Doc comments form write: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/queries-order.html > Description: > > The document only says this about unsorted queries: > > > After a query has produced an

Re: T is a mandatory date time separator in RFC3339 but documentation states differently

2023-11-13 Thread Erik Wienhold
On 2023-11-11 23:45 +0100, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/git.html > Description: > > >ISO 8601 specifies the use of uppercase letter T to separate the date and > time. PostgreSQL accep

Re: T is a mandatory date time separator in RFC3339 but documentation states differently

2023-11-13 Thread Erik Wienhold
On 2023-11-13 12:27 +0100, Roman Frołow wrote: > It seems I was wrong. > Now T is mandatory in ISO8601 and from RFC3339 it seems this requirement is > relaxed. Right. RFC 3339 is from 2002 and it references ISO 8601:1988 where T was optional. (Until today I didn't even know about the 2019 editio

Re: T is a mandatory date time separator in RFC3339 but documentation states differently

2023-11-13 Thread Erik Wienhold
On 2023-11-13 15:24 +0100, Erik Wienhold wrote: > I also noticed that when people say "ISO 8601" they usually mean RFC > 3389 or some subset of ISO 8601. Forgot this fine visualization of the differences: https://ijmacd.github.io/rfc3339-iso8601/ -- Erik

Re: T is a mandatory date time separator in RFC3339 but documentation states differently

2023-11-14 Thread Erik Wienhold
On 2023-11-13 17:23 +0100, Tom Lane wrote: > Erik Wienhold writes: > > On 2023-11-13 15:24 +0100, Erik Wienhold wrote: > >> I also noticed that when people say "ISO 8601" they usually mean RFC > >> 3389 or some subset of ISO 8601. > > > For

Re: T is a mandatory date time separator in RFC3339 but documentation states differently

2023-11-15 Thread Erik Wienhold
On 2023-11-15 08:16 +0100, Peter Eisentraut wrote: > The SQL standard does not refer to ISO 8601 to define date formats, it has > its own definitions. In fact, PostgreSQL implements more date formats than > the SQL standard requires. Really? Then what does the standard mean with section "Definit

Re: T is a mandatory date time separator in RFC3339 but documentation states differently

2023-11-15 Thread Erik Wienhold
On 2023-11-15 12:53 +0100, Peter Eisentraut wrote: > On 15.11.23 09:37, Erik Wienhold wrote: > > On 2023-11-15 08:16 +0100, Peter Eisentraut wrote: > > > The SQL standard does not refer to ISO 8601 to define date formats, it has > > > its own definitions. In fact, Post

Re: T is a mandatory date time separator in RFC3339 but documentation states differently

2023-11-19 Thread Erik Wienhold
On 2023-11-15 15:46 +0100, Tom Lane wrote: > Erik Wienhold writes: > > On 2023-11-15 12:53 +0100, Peter Eisentraut wrote: > >> I think we should reframe "ISO" to mean "ISO 9075" and remove all claims of > >> alignment with ISO 8601 and RFC 3339.

Re: T is a mandatory date time separator in RFC3339 but documentation states differently

2023-11-20 Thread Erik Wienhold
On 2023-11-20 08:14 +0100, Peter Eisentraut wrote: > On 19.11.23 21:34, Erik Wienhold wrote: > > * Making explicit references to ISO 8601:2004 where section numbers are > >referenced. Mostly in source comments but also a couple of places in > >the docs. This is abo

Re: [DOCS] Add example about date ISO format

2023-11-22 Thread Erik Wienhold
On 2023-11-22 10:14 +0100, Laurenz Albe wrote: > On Tue, 2023-11-21 at 23:33 -0500, Bruce Momjian wrote: > > On Fri, Feb 17, 2017 at 04:01:54PM +, juha.musto...@iki.fi wrote: > > > The following documentation comment has been logged on the website: > > > > > > Page: https://www.postgresql.org/

Re: [DOCS] Add example about date ISO format

2023-11-22 Thread Erik Wienhold
On 2023-11-22 17:58 +0100, Bruce Momjian wrote: > On Wed, Nov 22, 2023 at 02:02:02PM +0100, Erik Wienhold wrote: > > > > + > > > > + > > > > +to_char(current_timestamp AT TIME ZONE 'UTC', > > > > +'-MM

Re: [DOCS] Add example about date ISO format

2023-11-27 Thread Erik Wienhold
On 2023-11-24 18:29 +0100, Bruce Momjian wrote: > On Thu, Nov 23, 2023 at 09:29:39AM +0100, Laurenz Albe wrote: > > On Wed, 2023-11-22 at 11:58 -0500, Bruce Momjian wrote: > > > Okay, I moved it into the "Note" section that talked about ISO 8601 > > > output with "T", in the attached patch. > > >

Re: [DOCS] Add example about date ISO format

2023-11-27 Thread Erik Wienhold
On 2023-11-27 15:22 +0100, Alvaro Herrera wrote: > 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 > > a

[PATCH] Fix link to pg_ident_file_mappings

2024-02-20 Thread Erik Wienhold
The docs on pg_reload_conf() in v15, v16, and devel have an incorrect link to pg_ident_file_mappings. The attached patch fixes that. -- Erik >From 70ec25bf5e24c1b59c8a0b51afc04d87d9c26a0e Mon Sep 17 00:00:00 2001 From: Erik Wienhold Date: Wed, 21 Feb 2024 03:13:10 +0100 Subject: [PATCH]

Re: [PATCH] Fix link to pg_ident_file_mappings

2024-02-21 Thread Erik Wienhold
On 2024-02-21 08:50 +0100, Daniel Gustafsson wrote: > > On 21 Feb 2024, at 03:24, Erik Wienhold wrote: > > > > The docs on pg_reload_conf() in v15, v16, and devel have an incorrect > > link to pg_ident_file_mappings. The attached patch fixes that. > > Nice catch, will fix. Thanks! -- Erik

Re: Duplicates being removed from intarray on subtraction of another intarray

2024-03-18 Thread Erik Wienhold
operations use the same operator and not something like integer[] / integer[] which would be closer to the usual notation for set difference. [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=181ca96e7a730ba35e973d3361422e6d8a460f88 -- Erik >From 171ba158a1857e8d332

Re: Monetary Data Types Improvement

2024-03-18 Thread Erik Wienhold
On 2024-03-17 03:16 +0100, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/14/datatype-money.html > Description: > > It's not explicitly obvious that money doesn't behave like a normal numeric > type in th

Re: Monetary Data Types Improvement

2024-03-18 Thread Erik Wienhold
I wrote: > The attached patch does that. Hit send to early. -- Erik >From 281e684b242314d93120faf875c1456ecdddef2b Mon Sep 17 00:00:00 2001 From: Erik Wienhold Date: Mon, 18 Mar 2024 19:38:53 +0100 Subject: [PATCH v1] Add note about missing money operators --- doc/src/sgml/datatype.sgm

Re: Monetary Data Types Improvement

2024-03-20 Thread Erik Wienhold
On 2024-03-18 23:24 +0100, David Rowley wrote: > My vote would go to adding a deprecation notice to that section of the > docs. There's some talk [1] about how we discourage the usage of the > money type and that goes on to discuss the possibilities of moving it > into a contrib module. > > My ho

Re: ALTER TABLE atomicity with sub-commands

2024-04-02 Thread Erik Wienhold
On 2024-04-02 16:40 +0200, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/15/sql-altertable.html > Description: > > It is not entirely clear (to me) that ALTER TABLE statements with > comma-separated sub-

Re: nested tags in glossary entries in html docs

2024-04-12 Thread Erik Wienhold
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 https://www.postgres

Re: Documentation Chapter 16: 8.21

2024-04-22 Thread Erik Wienhold
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 "any

Re: nested tags in glossary entries in html docs

2024-04-25 Thread Erik Wienhold
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 stylesheet

Re: nested tags in glossary entries in html docs

2024-05-01 Thread Erik Wienhold
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 versio

nchar is undocumented

2024-05-04 Thread Erik Wienhold
9.F-Secure.com [3] https://www.postgresql.org/docs/16/functions-json.html#FUNCTIONS-JSON-CREATION-TABLE -- Erik >From 314e0ffc1efb854f603e325c13a39ba871aebbf5 Mon Sep 17 00:00:00 2001 From: Erik Wienhold Date: Sun, 5 May 2024 02:15:53 +0200 Subject: [PATCH] Document nchar data type alias Also ment

Re: nchar is undocumented

2024-05-06 Thread Erik Wienhold
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, th

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

2024-05-21 Thread Erik Wienhold
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

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

2024-05-23 Thread Erik Wienhold
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

Re: 17beta1 source download does not include docs & manpages

2024-05-28 Thread Erik Wienhold
On 2024-05-28 14:15 +0200, Marcel Hofstetter wrote: > 16.3 source download includes manpages and html docs. > > -bash-5.1$ tar tvf postgresql-16.3.tar | grep html | wc -l > 1166 > -bash-5.1$ tar tvf postgresql-16.3.tar | grep man1 | wc -l > 35 > > > 17beta1 does not. > > -bash-5.1$ tar tvf post

Re: 17beta1 source download does not include docs & manpages

2024-05-28 Thread Erik Wienhold
On 2024-05-28 21:02 +0200, Marcel Hofstetter wrote: > Unfortunately I'm unable to produce the html files on my > Solaris 11.4 CBE system (margay buildfarm member) > > -bash-5.1$ gmake html > gmake -C doc html > gmake[1]: Entering directory > '/export/home/marcel/source/postgresql-17beta1/doc' > gm

Re: I get ERROR: column "table_name" does not exist

2024-06-05 Thread Erik Wienhold
On 2024-06-04 21:50 +0200, PG Doc comments form wrote: > When using GET STACKED DIAGNOSTICS in PL/pgSQL accessing TABLE_NAME, > COLUMN_NAME, CONSTRAINT_NAME or SCHEMA_NAME throws an error. > > The function "shared.test_raise_exception": > https://github.com/rin-nas/postgresql-patterns-library/issu

Re: I get ERROR: column "table_name" does not exist

2024-06-06 Thread Erik Wienhold
n something like: RETURN jsonb_build_object('table', table_name); But that's still guesswork without seeing the actual function definition with your edits. > On Wed, Jun 5, 2024 at 6:32 PM Erik Wienhold wrote: > > > > On 2024-06-04 21:50 +0200, PG Doc comments form wrote: >

Re: I get ERROR: column "table_name" does not exist

2024-06-07 Thread Erik Wienhold
On 2024-06-07 14:24 +0200, Florian Koch wrote: > I made a gist with the error. > https://gist.github.com/floratmin/a4b404f0fd66b03a0428c07686b71410 The problem is the semicolon after PG_DATATYPE_NAME, causing the TABLE_NAME line to be a separate statement: >exception_datatype := PG_DATATYPE_N

Re: incorrect (incomplete) description for "alter domain"

2024-07-29 Thread Erik Wienhold
On 2024-07-29 13:02 +0200, PG Doc comments form wrote: > In the Synopsis section of > https://www.postgresql.org/docs/current/sql-alterdomain.html > this is incorrect (incomplete): > "ALTER DOMAIN name ADD domain_constraint [ NOT VALID ]" > It should be > "ALTER DOMAIN name ADD CONSTRAINT domain_c