> 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
> 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
> 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
>
> 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
> 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
> 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,
> 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
> 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
> 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
> 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
> 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
> 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
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
> 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]
> 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
> 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
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
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
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
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
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
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
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
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
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.
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
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/
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
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.
> >
>
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
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]
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
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
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
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
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
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-
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
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
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
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
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
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
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
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
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
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
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
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:
>
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
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
51 matches
Mail list logo