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 t

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 deallo

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:

Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases

gt; > > > [...] > > > > + and from_reference must be a table alias or non-hidden table_name > referenced > > in the FROM clause. > > > > For more information on each [...] > > Ah, good point.  I was searching for &q

Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases

gt; referenced > > in the FROM clause. > > > > For more information on each [...] > > Ah, good point. I was searching for "FOR UPDATE" so I missed that > section; updated patch attached. > > WFM. Thanks! David J.

Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases

need to change this spot to match > > where lock_strength can be one of > > [...] > > + and from_reference must be a table alias or non-hidden table_name referenced > in the FROM clause. > > For more information on each [...] Ah, good point. I was searching for "

Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases

On Mon, Nov 20, 2023 at 7:04 PM Bruce Momjian wrote: > On Fri, Nov 17, 2023 at 03:44:04PM -0700, David G. Johnston wrote: > > I don't like this particular solution to the stated complaint. When a > FROM > > entry has an alias it must be referenced via that alias anywhere it is > > referenced in

Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases

src/sgml/ref/select.sgml @@ -45,7 +45,7 @@ SELECT [ ALL | DISTINCT [ ON ( expressioncount | ALL } ] [ OFFSET start [ ROW | ROWS ] ] [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } { ONLY | WITH TIES } ] -[ FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE } [ OF table_name [, ...] ] [

Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases

.html > > Description: > > > > In the SELECT statement page the argument type of the (FOR SHARE/UPDATE) > OF > > clause is listed to be a table_name. This is not *quite* accurate - it > > should reference the *alias* assigned to the table if one was given. The > > dist

Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases

of the (FOR SHARE/UPDATE) OF > clause is listed to be a table_name. This is not *quite* accurate - it > should reference the *alias* assigned to the table if one was given. The > distinction is subtly important, as without this information the > documentation implies that the choice of

Cannot update the generation expression for a generated column / make the limitation explicit

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/15/sql-altertable.html Description: In the many forms of ALTER TABLE, described in https://www.postgresql.org/docs/current/sql-altertable.html, it appears that a generated column, defined wit

Re: update

On Sun, 2022-10-02 at 04:11 +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/14/tutorial-update.html > Description: > > the syntax used for update is a bit incorrect > if the

update

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/tutorial-update.html Description: the syntax used for update is a bit incorrect if the syntax used as it is mentioned in the site then the update will be done only to the last row in the

Clarifying docs on nuance of select and update policies

Hi y'all, I've got a proposed clarification to the documentation on the nuances of RLS behavior for update policies, and maybe a (humble) request for a change in behavior to make it more intuitive. I am starting with pgsql-docs since I think the documentation change is a good starting

Re: Update documentation page for translators

> On 17 Aug 2022, at 23:24, Bruce Momjian wrote: > > On Wed, Aug 17, 2022 at 10:58:55PM +0200, Daniel Gustafsson wrote: >>> On 17 Aug 2022, at 22:56, Bruce Momjian wrote: >> >>> Is there a reason this patch was not applied? >> >> Only that it fell of my radar, if you think it's adding value I'

Re: Update documentation page for translators

On Wed, Aug 17, 2022 at 10:58:55PM +0200, Daniel Gustafsson wrote: > > On 17 Aug 2022, at 22:56, Bruce Momjian wrote: > > > Is there a reason this patch was not applied? > > Only that it fell of my radar, if you think it's adding value I'm happy to get > it done now. Sure, it looked useful to m

Re: Update documentation page for translators

> On 17 Aug 2022, at 22:56, Bruce Momjian wrote: > Is there a reason this patch was not applied? Only that it fell of my radar, if you think it's adding value I'm happy to get it done now. -- Daniel Gustafsson https://vmware.com/

Re: Update documentation page for translators

afsson https://vmware.com/ > > diff --git a/doc/src/sgml/nls.sgml b/doc/src/sgml/nls.sgml > index d49f44f3f2..0b3c638594 100644 > --- a/doc/src/sgml/nls.sgml > +++ b/doc/src/sgml/nls.sgml > @@ -202,7 +202,9 @@ make update-po > Editing the PO Files > >

Re: Update wording of INSERT ON CONFLICT "rows proposed for insertion"

On Tue, Mar 8, 2022 at 5:14 PM David G. Johnston wrote: > > I suggest a minor rewording of: > > https://www.postgresql.org/docs/devel/sql-insert.html > > Concretely as attached. I did a bit more than minor work - I decided that actually calling it a table in the docs didn't really fit how it beh

Update wording of INSERT ON CONFLICT "rows proposed for insertion"

Hey, I suggest a minor rewording of: https://www.postgresql.org/docs/devel/sql-insert.html Current: "The SET and WHERE clauses in ON CONFLICT DO UPDATE have access to the existing row using the table's name (or an alias), and to [rows] proposed for insertion using the special excl

Re: Update documentation page for translators

> On 22 Oct 2021, at 13:12, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/11/nls-translator.html > Description: > > In the documentation for translators > (https://www.postgresql.org/docs/11/nls-tran

Update documentation page for translators

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/nls-translator.html Description: In the documentation for translators (https://www.postgresql.org/docs/11/nls-translator.html) it is mentioned to use any text editor for translating .po fi

Re: Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"

On Tue, Aug 17, 2021 at 11:18 PM radiodiversion wrote: > change sentence: "The search condition of the command (the WHERE clause) > is re-evaluated to see if the updated version of the row still matches the > search condition." > with sentence: "The search condition of the command (the WHERE clau

Re: Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"

David, I have some suggestions. but first i want to show how the current version of doc may look like for new readers. and why. I am sure that it looks pretty logical if you KNOW how it works, but it is not so clear if you WANT to learn that from documentation. explanation: first sentence: "they

Re: Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"

nts form < > nore...@postgresql.org> wrote: > >> >> "UPDATE, DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE commands ... >> ...If the first updater commits, the second updater will ignore the row if >> the first updater deleted it, otherwise it will atte

Re: Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"

On Tue, Aug 17, 2021 at 4:17 PM radiodiversion wrote: > I still think it would be great if this doc point was worded a little > differently in new editions. > > Suggestions are welcome. Without some idea of why you seemed to miss the two seemingly obvious references that I pointed out (including

Re: Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"

On Tue, Aug 17, 2021 at 3:56 PM PG Doc comments form wrote: > > "UPDATE, DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE commands ... > ...If the first updater commits, the second updater will ignore the row if > the first updater deleted it, otherwise it will attempt to apply i

Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/transaction-iso.html Description: hello! documentation for "read committed" says that: "UPDATE, DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE commands ... ...If th

Re: Has the Update savepoint example outlived its usefulness?

On Thu, Jun 24, 2021 at 4:20 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > On 04.06.21 02:08, David G. Johnston wrote: > > The example in the update documentation that does an upsert using a > > savepoint seems like it should just go away now tha

Re: Has the Update savepoint example outlived its usefulness?

On 04.06.21 02:08, David G. Johnston wrote: The example in the update documentation that does an upsert using a savepoint seems like it should just go away now that we have insert...on conflict.  Making an explicit reference (and link) to that feature in the Update documentation should be

Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM

On Wed, 2021-06-02 at 18:16 +0900, Masahiko Sawada wrote: > > > We should add a line that indicates that there is a limitation (that > > > should be IMO, backported to documentation of earlier versions as it > > > affects all supported versions), at least until such limitation is > > > lifted. > >

Has the Update savepoint example outlived its usefulness?

Hey, The example in the update documentation that does an upsert using a savepoint seems like it should just go away now that we have insert...on conflict. Making an explicit reference (and link) to that feature in the Update documentation should be added in its place (well, under notes). David

Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM

On Wed, May 5, 2021 at 7:03 PM Laurenz Albe wrote: > > On Mon, 2021-05-03 at 13:48 -0300, Martín Marqués wrote: > > We should add a line that indicates that there is a limitation (that > > should be IMO, backported to documentation of earlier versions as it > > affects all supported versions), at

Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM

On Mon, 2021-05-03 at 13:48 -0300, Martín Marqués wrote: > We should add a line that indicates that there is a limitation (that > should be IMO, backported to documentation of earlier versions as it > affects all supported versions), at least until such limitation is > lifted. Here is a patch for

Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM

Hi, There's a well known limitation in the amount of memory that any VACUUM process can use, capped at 1GB now. This is not reflected in the documentation https://www.postgresql.org/docs/current/runtime-config-resource.html We should add a line that indicates that there is a limitation (that sho

Re: Update to reflect that TLS1 and TLSv1.1 are now deprecated

> On 24 Mar 2021, at 21:07, Peter Eisentraut > wrote: > > On 24.03.21 10:49, Daniel Gustafsson wrote: >> The recently published RFC 8996 deprecates the use of TLSv1 and TLSv1.1, the >> attached rewords where we say our default of 1.2 is industry best practice >> with >> a link to the authoritat

Re: Update to reflect that TLS1 and TLSv1.1 are now deprecated

On 24.03.21 10:49, Daniel Gustafsson wrote: The recently published RFC 8996 deprecates the use of TLSv1 and TLSv1.1, the attached rewords where we say our default of 1.2 is industry best practice with a link to the authoritative source. The "industry best practices" the original text refers to

Re: Update to reflect that TLS1 and TLSv1.1 are now deprecated

On 3/24/21 5:49 AM, Daniel Gustafsson wrote: > The recently published RFC 8996 deprecates the use of TLSv1 and TLSv1.1, the > attached rewords where we say our default of 1.2 is industry best practice > with > a link to the authoritative source. I would s/as of/stated in/ and add a comma after RF

Update to reflect that TLS1 and TLSv1.1 are now deprecated

The recently published RFC 8996 deprecates the use of TLSv1 and TLSv1.1, the attached rewords where we say our default of 1.2 is industry best practice with a link to the authoritative source. -- Daniel Gustafsson https://vmware.com/ rfc_8996.diff Description: Binary data

RE: SELECT ... FOR UPDATE OF

on locking clauses is long and densely written, and a direct mention of the syntax element would help the reader find the relevant information. Even an example using FOR UPDATE OF ... might be a useful addition. > I'll agree that the docs don't indicate that "table_name"

Re: SELECT ... FOR UPDATE OF

On Thu, Dec 17, 2020 at 5:29 AM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/13/sql-select.html > Description: > > The FOR UPDATE clause of the SELECT statement can be followed by a

SELECT ... FOR UPDATE OF

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/sql-select.html Description: The FOR UPDATE clause of the SELECT statement can be followed by an OF clause, but this is never explained at all in the documentation, as far as I can tell

Re: Update limitations for declarative partitioning

On Mon, Aug 31, 2020 at 11:18:55AM +0900, Michael Paquier wrote: > Indeed, there is no fix in the code tree. Alvaro? If there is no > update, I'll go fix that myself. For the archives: this has been done with 97dc0d1. (Thanks, Alvaro!) -- Michael signature.asc Description: PGP signature

Re: Update limitations for declarative partitioning

On Sun, Aug 30, 2020 at 11:39:59PM +0200, Erwin Brandstetter wrote: > Looking at > https://www.postgresql.org/docs/devel/ddl-partitioning.html#DDL-PARTITIONING-DECLARATIVE-LIMITATIONS > ... the issue seems unchanged? Indeed, there is no fix in the code tree. Alvaro? If there is no upd

Re: Update limitations for declarative partitioning

Looking at https://www.postgresql.org/docs/devel/ddl-partitioning.html#DDL-PARTITIONING-DECLARATIVE-LIMITATIONS ... the issue seems unchanged? Regards Erwin On Sat, 8 Aug 2020 at 05:38, Alvaro Herrera wrote: > On 2020-Aug-08, Erwin Brandstetter wrote: > > > - But the manual still warns at > >

Re: Update limitations for declarative partitioning

On 2020-Aug-08, Erwin Brandstetter wrote: > - But the manual still warns at > https://www.postgresql.org/docs/13/ddl-partitioning.html#DDL-PARTITIONING-DECLARATIVE-LIMITATIONS > > BEFORE ROW triggers, if necessary, must be defined on individual > > partitions, not the partitioned table. > > > >

Update limitations for declarative partitioning

The release notes for pg 13 advertise a new feature in https://www.postgresql.org/docs/13/release-13.html#DDL-PARTITION-PRUNING - > > Allow BEFORE row-level triggers > on partitioned tables > (Álvaro Herrera) > > These triggers cannot change which

Re: 【memory barrier】Should we update the README.barrier description.

On Sun, 10 May 2020 at 02:01, postgresql_2...@163.com < postgresql_2...@163.com> wrote: > Hi > > When I read the introduction of Weaknesses of Memory Barriers in > README.barrier, the following maybe out-of-date now. > > Even very simple write operations often require additional synchronization. >

【memory barrier】Should we update the README.barrier description.

Hi When I read the introduction of Weaknesses of Memory Barriers in README.barrier, the following maybe out-of-date now. Even very simple write operations often require additional synchronization. For example, it's not safe for multiple writers to simultaneously execute this code (supposing x is

Re: No docs for interaction of ON DELETE/UPDATE and permissions

On Tue, 2020-02-25 at 10:30 -0800, David Glasser wrote: > > I am not sure if CREATE TABLE is the perfect place; another place that > > would offer ifself is > > https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-FK > > , > > where foreign key constraints are explained. >

Re: No docs for interaction of ON DELETE/UPDATE and permissions

On Tue, Feb 25, 2020 at 1:54 AM Laurenz Albe wrote: > I am not sure if CREATE TABLE is the perfect place; another place that > would offer ifself is > https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-FK > , > where foreign key constraints are explained. I had found th

Re: No docs for interaction of ON DELETE/UPDATE and permissions

On Mon, 2020-02-24 at 14:45 -0800, David Glasser wrote: > I was planning to add a new table TA only writable by user A, with a foreign > key reference with > ON DELETE CASCADE to another table TB only writable by user B. My hope was > that user B would > still be allowed to delete rows in TB and

No docs for interaction of ON DELETE/UPDATE and permissions

I was planning to add a new table TA only writable by user A, with a foreign key reference with ON DELETE CASCADE to another table TB only writable by user B. My hope was that user B would still be allowed to delete rows in TB and cause cascading deletions in table TA, and some manual investigatio

Log Rotation Documentation Update

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/runtime-config-logging.html Description: Hi all: We recently ran into an unusual case where the following occurred: - PG log directory is a separate filesystem from PG data and other oper

Re: Update documentation - include supported windows version for release 12

On 10/17/19 3:12 AM, Michael Paquier wrote: > On Tue, Oct 15, 2019 at 11:56:38AM +0200, Emil Iggland wrote: >> PostgreSQL 12 has been released and is available for download from the >> EnterpriseDB website. >> The documentation should be updated to reflect the supported versions. >> Attached patch

Re: Update documentation - include supported windows version for release 12

On Tue, Oct 15, 2019 at 11:56:38AM +0200, Emil Iggland wrote: > PostgreSQL 12 has been released and is available for download from the > EnterpriseDB website. > The documentation should be updated to reflect the supported versions. > Attached patch does that. > @@ -47,7 +47,12 @@ This download is

Update documentation - include supported windows version for release 12

PostgreSQL 12 has been released and is available for download from the EnterpriseDB website. The documentation should be updated to reflect the supported versions. Attached patch does that. -- Emil Iggland Westmansgatan 37, SE-582 16 Linköping Direkt: +46(0)70 - 964 27 87 Växel: +46(0)13 - 36 46

Update and modernization to intro.sgml

Hey, I sent this to -hackers where it went one round but it probably makes more sense here. JD -- Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc Postgres centered full stack support, consulting and development. Advocate: @amplifypostgres || Get help: https://commandpro

suggestion: "See also" for create rule and Rules on INSERT, UPDATE, and DELETE

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/sql-createrule.html Description: Hi, It would be nice for newbies if https://www.postgresql.org/docs/11/sql-createrule.html and https://www.postgresql.org/docs/11/rules-update.html are

Re: Update section on NFS

On 2019-04-26 09:41, Thomas Munro wrote: > Those options are Linux-specific -- maybe just say so? committed with that change -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Update section on NFS

On Wed, Apr 24, 2019 at 11:17 PM Joe Conway wrote: > On 4/24/19 4:54 AM, Peter Eisentraut wrote: > > On 2019-04-23 18:53, Tom Lane wrote: > >> Peter Eisentraut writes: > >>> On 2019-04-23 16:15, Joe Conway wrote: > I don't think so. Not sure if you have an account at Red Hat, but this >

Re: Update section on NFS

On 4/24/19 4:54 AM, Peter Eisentraut wrote: > On 2019-04-23 18:53, Tom Lane wrote: >> Peter Eisentraut writes: >>> On 2019-04-23 16:15, Joe Conway wrote: I don't think so. Not sure if you have an account at Red Hat, but this ticket covers it: https://access.redhat.com/solutions/4819

Re: Update section on NFS

Eisentraut Date: Wed, 24 Apr 2019 10:53:40 +0200 Subject: [PATCH v2] doc: Update section on NFS --- doc/src/sgml/runtime.sgml | 94 ++- 1 file changed, 63 insertions(+), 31 deletions(-) diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 3

Re: Update section on NFS

Peter Eisentraut writes: > On 2019-04-23 16:15, Joe Conway wrote: >> I don't think so. Not sure if you have an account at Red Hat, but this >> ticket covers it: >> https://access.redhat.com/solutions/48199 > That discusses the equally-named export options on the NFS server, not > the mount option

Re: Update section on NFS

On 2019-04-23 16:15, Joe Conway wrote: > On 4/23/19 9:47 AM, Peter Eisentraut wrote: >> On 2019-04-23 14:31, Joe Conway wrote: >>> Looks like you dropped the advice WRT the asynchronous mount option. >>> Isn't that is still relevant? >> >> I don't think that advice was correct. An async mounted NF

Re: Update section on NFS

On 4/23/19 9:47 AM, Peter Eisentraut wrote: > On 2019-04-23 14:31, Joe Conway wrote: >> Looks like you dropped the advice WRT the asynchronous mount option. >> Isn't that is still relevant? > > I don't think that advice was correct. An async mounted NFS file system > will flush data on fsync, whi

Re: Update section on NFS

On 2019-04-23 14:31, Joe Conway wrote: > Looks like you dropped the advice WRT the asynchronous mount option. > Isn't that is still relevant? I don't think that advice was correct. An async mounted NFS file system will flush data on fsync, which is what one wants. -- Peter Eisentraut

Re: Update section on NFS

On 2019-04-23 13:00, Martín Marqués wrote: > Didn''t read the proposed patch, but would like to point out that I > would also add that it has to be mounted without file attribute caching. Why? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remo

Re: Update section on NFS

On 4/23/19 6:10 AM, Peter Eisentraut wrote: > Attached is a patch that rewrites the section on NFS. The old section > was ancient and didn't seem very helpful. > > AFAIK, the only strict requirement for using NFS with PostgreSQL is the > hard mount. Anything else we should mention? > > I also r

Re: Update section on NFS

El 23/4/19 a las 07:10, Peter Eisentraut escribió: > Attached is a patch that rewrites the section on NFS. The old section > was ancient and didn't seem very helpful. > > AFAIK, the only strict requirement for using NFS with PostgreSQL is the > hard mount. Anything else we should mention? Didn'

Update section on NFS

ices From 6b9430b395997955be718244d0061eceb1319a9e Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Tue, 23 Apr 2019 12:03:57 +0200 Subject: [PATCH] doc: Update section on NFS --- doc/src/sgml/runtime.sgml | 71 ++- 1 file changed, 40 insertions(+), 31 deletions(-) d

Re: Update to equivalent SQL in 8.1.4. Serial Types

On 2019-02-20 13:47, PG Doc comments form wrote: > CREATE TABLE tablename ( > colname SERIAL > ); > > is equivalent to > > CREATE SEQUENCE tablename_colname_seq; > CREATE TABLE tablename ( > colname integer NOT NULL DEFAULT nextval('tablename_colname_seq') > ); > ALTER SEQUENCE tablename_

Update to equivalent SQL in 8.1.4. Serial Types

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/datatype-numeric.html Description: In 8.1.4. Serial Types it says that CREATE TABLE tablename ( colname SERIAL ); is equivalent to CREATE SEQUENCE tablename_colname_seq; CREATE TAB

New vs old values collision in UPDATE RETURNING docs

UPDATE command after each row is updated. What we have in the wild (Pg8..11): * when using field names, expression represents NEW values after update; * when using sub-selects or joined table references, expression represents OLD values before update. POC code: create temporary table test(id int

UPDATE OF on REPLICA TRIGGERS

We tried a lot, maybe for some days, to have some triggers working properly on a replica server. So we read a discussion that is not possible to have UPDATE OF in a trigger which works only on REPLICA. Our tests was production using version 10 and replica using version 11. I thing it would be

Re: Doc update

On Thu, Aug 9, 2018 at 08:54:16AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/static/sql-grant.html > Description: > > This line: > > The entries shown by \dp are interpreted thus: > > Sho

Doc update

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/10/static/sql-grant.html Description: This line: The entries shown by \dp are interpreted thus: Should be updated to: The entries shown by \dp and \l are interpreted thus:

Re: search.cpan.org is EOL, update links

> On 29 Jun 2018, at 15:24, Michael Paquier wrote: > > On Fri, Jun 29, 2018 at 08:29:16AM +0200, Daniel Gustafsson wrote: >> Good point, we might as well do that too. Fixed those two and an additional >> one in the attached updated version. > > Did you notice the paragraph at the top of ppport.

Re: search.cpan.org is EOL, update links

On Fri, Jun 29, 2018 at 08:29:16AM +0200, Daniel Gustafsson wrote: > Good point, we might as well do that too. Fixed those two and an additional > one in the attached updated version. Did you notice the paragraph at the top of ppport.h? This is a file automatically generated so it does not sound

Re: search.cpan.org is EOL, update links

e maintained for a >> long >> time, we might as well update to avoid the risk of stale redirects. Attached >> patch changes the few links we have to instead use metacpan. > > Okay, let's fix that. > > While working on the links for CPAN, perhaps these should be

Re: search.cpan.org is EOL, update links

On Thu, Jun 28, 2018 at 01:00:47PM +0200, Daniel Gustafsson wrote: > search.cpan.org has now been EOL’d and turned off, with all URLs redirecting > to > metacpan.org [1]. While the redirects are likely to the maintained for a long > time, we might as well update to avoid the r

search.cpan.org is EOL, update links

search.cpan.org has now been EOL’d and turned off, with all URLs redirecting to metacpan.org [1]. While the redirects are likely to the maintained for a long time, we might as well update to avoid the risk of stale redirects. Attached patch changes the few links we have to instead use metacpan

SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.5/static/sql-select.html Description: In the SELECT statement page the argument type of the (FOR SHARE/UPDATE) OF clause is listed to be a table_name. This is not *quite* accurate - it

Re: Keep me update every new development

On Sunday, March 18, 2018, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/9.1/static/sql-listen.html > Description: > > Keep me update every new development > Sorry, listen/notify

Keep me update every new development

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.1/static/sql-listen.html Description: Keep me update every new development

Re: Update encryption options doc for SCRAM-SHA-256

Thanks for your attention to this. I'm definitely not a cryptography expert, but it seems to me that the actual mechanisms (MD5, SHA-256) are more important than the protocols used to negotiate them (SASL, SCRAM). When some security expert unfamiliar with PostgreSQL goes over itss documentation to

Re: Update encryption options doc for SCRAM-SHA-256

er Eisentraut Date: Sat, 3 Feb 2018 11:29:23 -0500 Subject: [PATCH] doc: Update mentions of MD5 in the documentation --- doc/src/sgml/runtime.sgml | 34 +- 1 file changed, 9 insertions(+), 25 deletions(-) diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/run

Update encryption options doc for SCRAM-SHA-256

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/10/static/encryption-options.html Description: Section "18.8. Encryption Options" only mentions MD5 as the password storage encryption mechanism, although PostgreSQL 10 introduced the superio