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
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
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 syntax used as it is men
> 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'
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
> 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/
Is there a reason this patch was not applied?
---
On Fri, Nov 12, 2021 at 02:46:40PM +0100, Daniel Gustafsson wrote:
> > On 22 Oct 2021, at 13:12, PG Doc comments form
> > wrote:
> >
> > The following documentation comme
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
> 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
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.
> >
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
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
> 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
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
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
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
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
update, I'll g
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
> >
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.
> >
>
>
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
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
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
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
>
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
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/48199
>
>> That discusses the equally-named export opt
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
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
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
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
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
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
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'
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_
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
On 2/2/18 18:42, PG Doc comments form wrote:
> 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
> encrypti
35 matches
Mail list logo
