On 2/25/22 12:39 PM, Tom Lane wrote:
Jeff Davis writes:
On Thu, 2022-02-24 at 20:47 -0500, Tom Lane wrote:
... and, since we can't readily enforce that the client only sends
those cleartext passwords over suitably-encrypted connections, this
could easily be a net negative for security. Not su
On 3/1/22 8:31 AM, Stephen Frost wrote:
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
On Mon, Feb 28, 2022 at 04:42:55PM -0500, Stephen Frost wrote:
Keeping it around will just push out the point at which everyone will
finally be done with it, as there's really only two groups: tho
On 2/28/22 5:26 AM, Peter Eisentraut wrote:
On 17.02.22 20:25, samay sharma wrote:
A use case where this is useful are environments where you want
authentication to be centrally managed across different services. This
is a common deployment model for cloud providers where customers like
to use
On 3/2/22 3:24 AM, Peter Eisentraut wrote:
On 01.03.22 22:17, Jonathan S. Katz wrote:
If you're moving to a newer version of PostgreSQL, you likely have to
update your connection drivers anyway (rebuilt against new libpq,
supporting any changes in the protocol, etc). I would prefer more
On 3/2/22 10:30 AM, Stephen Frost wrote:
Greetings,
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
On 02.03.22 15:16, Jonathan S. Katz wrote:
I find that a lot of people are still purposely using md5. Removing it
now or in a year would be quite a disruption.
What are the
On 3/3/22 12:23 PM, Bruce Momjian wrote:
On Thu, Mar 3, 2022 at 10:45:42AM +0100, Peter Eisentraut wrote:
On 02.03.22 16:45, Jonathan S. Katz wrote:
By that argument, we should have kept "password" (plain) as an
authentication method.
For comparison, the time between adding md5 an
Hi,
Attached is a draft of the release announcement for the upcoming
2020-11-12 update release.
Corrections and feedback welcome, so long as it is submitted by
2020-11-11 AoE[1].
Thanks!
Jonathan
[1] https://en.wikipedia.org/wiki/Anywhere_on_Earth
The PostgreSQL Global Development Group has re
On 11/16/20 4:27 AM, Dave Page wrote:
> Hi,
>
> This is more of a head-ups than anything else, as I suspect this may
> come up in various forums.
>
> The PostgreSQL installers for macOS (from EDB, possibly others too)
> create the data directory in /Library/PostgreSQL//data. This
> has been the c
Hi,
Attached is a draft of the release announcement for the upcoming
2021-02-11 cumulative update release. Please review for technical
accuracy (I did screen for typos, but would not be surprised if any
slipped in).
Please provide feedback on this thread no later than 2020-02-10 AoE[1].
Thanks!
On 2/8/21 11:30 PM, e...@xs4all.nl wrote:
>> On 02/08/2021 11:40 PM Jonathan S. Katz wrote:
>>
>>
>> Hi,
>>
>> Attached is a draft of the release announcement for the upcoming
>> 2021-02-11 cumulative update release. Please review for technical
>
&
On 2/8/21 6:11 PM, Noah Misch wrote:
> On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote:
>> This update also fixes over 80 bugs that were reported in the last several
>> months. Some of these issues only affect version 13, but may also apply to
>> other
On 2/10/21 10:19 AM, Chapman Flack wrote:
> On 02/10/21 10:15, Jonathan S. Katz wrote:
>> On 2/8/21 6:11 PM, Noah Misch wrote:
>>> On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote:
>>>> Some of these issues only affect version 13, but may also apply to
Hi,
On 7/13/20 12:53 PM, Jonathan S. Katz wrote:
> Hi,
>
> The PostgreSQL 13 Release Management Team is pleased to announce the
> release date of PostgreSQL 13 Beta 3 is set to 2020-08-13, which is the
> same day as the cumulative update release[1]. Please be sure to have
Hi,
Attached is a draft of the release announcement for the update release
on 2020-08-13, which also includes the release of PostgreSQL 13 Beta 3.
Reviews and feedback are welcome.
This is a fairly hefty release announcement as it includes notes both
about the update release and the beta. I tried
Hi,
First, on behalf of the PostgreSQL 13 RMT, thank you everyone for your
hard work not only building all of the features that are going into
PostgreSQL 13, but for the diligence and work in stabilizing the
release. We have now reached the point of the release cycle where we can
start making deci
Hi,
On 5/4/20 11:16 PM, Bruce Momjian wrote:
> I have committed the first draft of the PG 13 release notes. You can
> see them here:
>
> https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting. The community doc
> build should happen in a few hou
Hi,
On 9/2/20 2:13 PM, Jonathan S. Katz wrote:
> * PostgreSQL 13 Release Candidate 1 (RC1) will be released on September
> 17, 2020.
>
> * In absence of any critical issues, PostgreSQL 13 will become generally
> available on September 24, 2020.
>
> The aim is to have all o
On 9/10/20 1:14 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> Attached is a proposal for the "major enhancements" section. I borrowed
>> from the press release[1] but tried to stay true to the release notes
>> format and listed out the enhancements t
Hi,
Since PostgreSQL 12 (0516c61b756e39) we have allowed for the ability to
set "clientcert=verify-full" against various HBA authentication methods.
This provides the ability to provide "multi-factor authentication" e.g.
a client must provide both a valid certificate with a CN (or DN) that
ma
On 10/26/21 3:26 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
With certificate-based authentication methods and other methods, we
allow for users to specify a mapping in pg_ident, e.g. if one needs to
perform a rewrite on the CN to match the username that is specified
within
On 10/27/21 12:14 PM, Jacob Champion wrote:
On Tue, 2021-10-26 at 18:16 -0400, Tom Lane wrote:
Per "21.2. User Name Maps", I think that the map parameter is supposed
to translate from the startup packet's user name to the SQL role name.
I may have misunderstood what you wrote, but IIUC the sta
Hi,
Attached please find a draft of the release announcement for 2021-11-11.
Please provide any feedback no later than Thu, Nov 11, 2021 0:00 AoE[1].
Thanks!
Jonathan
[1] https://en.wikipedia.org/wiki/Anywhere_on_Earth
The PostgreSQL Global Development Group has released an update to all sup
On 11/9/21 12:10 PM, Erik Rijkers wrote:
Op 09-11-2021 om 17:25 schreef Jonathan S. Katz:
Attached please find a draft of the release announcement for 2021-11-11.
"overflowed-subsraction" should probably be
"overflowed-subtraction"
Actually it should be "overf
On 11/9/21 3:19 PM, Justin Pryzby wrote:
On Tue, Nov 09, 2021 at 11:25:37AM -0500, Jonathan S. Katz wrote:
* Fix is when creating a new range type with `CREATE TYPE` that could cause
problems for later event triggers or subsequent executions of the `CREATE TYPE`
command.
I don't know wha
On 11/9/21 10:39 PM, Noah Misch wrote:
On Tue, Nov 09, 2021 at 11:25:37AM -0500, Jonathan S. Katz wrote:
Attached please find a draft of the release announcement for 2021-11-11.
Please provide any feedback no later than Thu, Nov 11, 2021 0:00 AoE[1].
Bug Fixes and Improvements
On 11/10/21 10:47 PM, Noah Misch wrote:
On Wed, Nov 10, 2021 at 02:07:43PM -0500, Jonathan S. Katz wrote:
On 11/9/21 10:39 PM, Noah Misch wrote:
On Tue, Nov 09, 2021 at 11:25:37AM -0500, Jonathan S. Katz wrote:
Attached please find a draft of the release announcement for 2021-11-11.
Please
Hi,
The Release Management Team (RMT) for the PostgreSQL 11 release
has been assembled and has determined that the feature freeze date
for the PostgreSQL 11 release will be April 7, 2018. This means that any
feature that will be going into the PostgreSQL 11 release must be
committed before 2018-04
> On Apr 5, 2018, at 11:08 PM, Peter Eisentraut
> wrote:
>
> On 4/1/18 03:27, Pavel Stehule wrote:
>> I don't share option so CSV format should be exactly same like CSV COPY.
>> COPY is designed for backups - and header is not too important there.
>> When I seen some csv, then there usually hea
Hi Pavel,
> On Apr 6, 2018, at 1:38 AM, Pavel Stehule wrote:
>
>
>
> 2018-04-06 5:46 GMT+02:00 Jonathan S. Katz <mailto:jk...@postgresql.org>>:
>
> > On Apr 5, 2018, at 11:08 PM, Peter Eisentraut
> > > <mailto:peter.eisentr...@2ndquadran
> On Apr 6, 2018, at 6:53 PM, Robert Haas wrote:
>
> On Tue, Mar 27, 2018 at 9:51 AM, Jonathan S. Katz
> wrote:
>> The Release Management Team (RMT) for the PostgreSQL 11 release
>> has been assembled and has determined that the feature freeze date
>> for the
> On Apr 6, 2018, at 6:57 PM, Robert Haas wrote:
>
> On Fri, Apr 6, 2018 at 6:54 PM, Jonathan S. Katz wrote:
>> Yes. It follows the format from the previous ones, i.e:
>>
>> https://www.postgresql.org/message-id/ca+tgmoy56w5fozeeo+i48qehl+bsvtwy-q1m0xjuhucwggw...@
> On Mar 21, 2018, at 10:59 PM, Amit Langote
> wrote:
>
> Hi David.
>
> On 2018/03/21 23:31, David Steele wrote:
>> Hi Amit,
>>
>> On 3/6/18 9:44 AM, David Steele wrote:
>>> On 3/2/18 2:27 AM, Amit Langote wrote:
On 2018/03/02 15:58, Andres Freund wrote:
> On 2018-02-02 17:00:24 -050
> On Apr 9, 2018, at 8:28 AM, Peter Eisentraut
> wrote:
>
> On 4/7/18 11:16, Jonathan S. Katz wrote:
>> The last line yielding:
>>
>> ERROR: syntax error at or near "TRUE"
>> LINE 3: FOR VALUES IN (TRUE);
>>
>> [Omitted fro
> On Apr 9, 2018, at 10:06 AM, Tom Lane wrote:
>
> "Jonathan S. Katz" writes:
>> +1 based on running the above scenario on my 10.3 instance and
>> receiving the same error. Is there a chance the fix could make it into
>> 10.4 then?
>
> It's
> On Apr 10, 2018, at 1:22 PM, Tom Lane wrote:
>
> David Rowley writes:
>> On 11 April 2018 at 03:34, Tom Lane wrote:
>>> Well, that just begs the question: why do these expressions need to
>>> be immutable? What we really want, I think, is to evaluate them
>>> and reduce them to constants.
> On Apr 11, 2018, at 4:33 AM, Kyotaro HORIGUCHI
> wrote:
>
> Thank you for the comments.
>
> At Wed, 11 Apr 2018 13:51:55 +0900, Amit Langote
> wrote in
> <3d0fda29-986c-d970-a22c-b4bd44f56...@lab.ntt.co.jp>
>> Horiguchi-san,
>>
>> Thanks for working on this.
>>
>> On 2018/04/11 13:20, K
> On Apr 11, 2018, at 11:54 AM, Tom Lane wrote:
>
> Robert Haas writes:
>> On Wed, Apr 11, 2018 at 10:53 AM, Tom Lane wrote:
>>> What *does* take time is adding a link to the commit, so I'd happily
>>> drop that step. As Peter says, you can usually look in the commit
>>> log if you care.
>
>
> On Apr 11, 2018, at 4:58 PM, Peter Eisentraut
> wrote:
>
> On 4/11/18 10:53, Tom Lane wrote:
>> It's not that much work to move the items rather than remove them,
>
> Well, toward the end of the cycle, when the list of closed items is
> quite long, then it does become a bit of a burden to ca
Hi,
> On Apr 12, 2018, at 12:12 AM, Kyotaro HORIGUCHI
> wrote:
>
> Hello.
>
> At Wed, 11 Apr 2018 09:43:37 -0400, "Jonathan S. Katz"
> mailto:jonathan.k...@excoventures.com>>
> wrote in <mailto:efeba03d-effc-46e2-a0f7-41d004870..
> On Apr 12, 2018, at 9:24 AM, Ashutosh Bapat
> wrote:
>
> On Thu, Apr 12, 2018 at 6:52 PM, Alvaro Herrera
> wrote:
>>
>> Now, maybe what you suggest for open items is to create a separate view
>> using much of the commitfest app code, say
>> https://commitfest.postgresql.org/openitems/NNN
>
> On Apr 12, 2018, at 2:36 PM, Christophe Pettus wrote:
>
>
>> On Apr 12, 2018, at 09:17, Robert Haas wrote:
>> Hmm, that's interesting. So you want the children to inherit the
>> parent's tablespace when they are created, but if the parent's
>> tablespace is later changed, the existing child
> On Apr 12, 2018, at 3:10 PM, Alvaro Herrera wrote:
>
> Robert Haas wrote:
>> On Thu, Apr 12, 2018 at 2:40 PM, Jonathan S. Katz
>> wrote:
>>> If there are no strong objections I am going to add this to the “Older Bugs”
>>> section of Open Items in a litt
> On Apr 23, 2018, at 12:33 PM, Tom Lane wrote:
>
> Amit Langote writes:
>> On 2018/04/22 2:29, Tom Lane wrote:
>>> I propose the attached slightly-less-invasive version of Amit's original
>>> patch as what we should do in v10 and v11, and push the patch currently
>>> under discussion out to v1
Hi,
PostgreSQL 12 Beta 4 will be released on 2019-09-12. Please make sure
that fixes for bugs and other open items[1] are committed by the end of
the weekend.
Thanks for all of your efforts in getting PostgreSQL 12 ready for
general availability!
Jonathan
[1] https://wiki.postgresql.org/wiki/Po
On 9/6/19 9:56 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 2019-09-05 22:27, Jonathan S. Katz wrote:
>>> PostgreSQL 12 Beta 4 will be released on 2019-09-12. Please make sure
>>> that fixes for bugs and other open items[1] are committed by the end of
>>
Hi,
Please see attached draft of the PG12 Beta 4 press release.
I went through the list of open items that were resolved before beta
4[1] for the detailed please. Please let me know if I described any of
them incorrectly, or if you believe that any other fixes should be on
the list.
Thanks!
Jon
Hi,
On 7/29/19 8:33 PM, Chapman Flack wrote:
> On 07/29/19 18:27, Alexander Korotkov wrote:
>
>> What do you think about renaming existing operator from like_regex to
>> pg_like_regex? Or introducing special flag indicating that PostgreSQL
>> regex engine is used ('p' for instance)?
>
> Renamin
On 9/16/19 11:20 AM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> It sounds like the easiest path to completion without potentially adding
>> futures headaches pushing back the release too far would be that, e.g.
>> these examples:
>
>>
On 9/16/19 5:10 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> On 9/16/19 11:20 AM, Tom Lane wrote:
>>> I think we could possibly get away with not having any special marker
>>> on regexes, but just explaining in the documentation that "features
&g
On 9/16/19 6:39 PM, Jonathan S. Katz wrote:
> My main question is "where" -- I'm thinking somewhere in the JSON
> path[2] section. After reading your email 3 times, I may have enough
> knowledge to attempt some documentation on the regexp in JSON path.
Here is said at
On 9/17/19 12:09 PM, Erik Rijkers wrote:
> On 2019-09-17 17:38, Jonathan S. Katz wrote:
>> [regex.patch]
Thanks for the review!
> "Several other parts of the SQL standard
> also define LIKE_REGEX equivalents that refer
> to this implementation, including the
> SQL/J
On 9/17/19 1:09 PM, Peter Eisentraut wrote:
>> * Client- and server-side encryption for authentication using GSSAPI
>
> This is on the wire encryption, so I don't know why it says client-side
> and server-side. Proposal:
>
> * Encrypted TCP/IP connections using GSSAPI encryption
+1, though I wo
On 9/17/19 4:10 PM, Peter Eisentraut wrote:
> On 2019-09-17 21:55, Jonathan S. Katz wrote:
>>> * Encrypted TCP/IP connections using GSSAPI encryption
>>
>> +1, though I would s/GSSAPI encryption/ with s/GSSAPI authentcation/
>
> But you're not encryp
On 9/17/19 6:40 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> v2 attached. Thanks!
>
> I whacked this around some (well, quite a bit actually);
So I see :) Thanks.
> notably,
> I thought we'd better describe things that are in our engine but
> n
On 9/17/19 10:00 PM, Chapman Flack wrote:
> On 09/17/19 21:13, Jonathan S. Katz wrote:
>
>> to), which describes being able to use "&#[0-9]+;" and "&#[0-9a-fA-F]+;"
>
> Er, that is, "&#[0-9]+;" and "&#x[0-9a-fA-F]+;"
On 9/19/19 12:25 PM, Tom Lane wrote:
> I wrote:
>> I found a spot that seemed like a reasonable place, and added some
>> coverage of the point. Updated patch attached.
>
> Doc patch pushed.
Thanks! I did not get to review them last night but upon review not too
long ago, they looked great.
>> I
On 9/19/19 3:48 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> I looked at the patch, but did not test it. From what I can see, it
>> looks good, but perhaps we add a test in it to show that single-quoted
>> literals are unsupported?
>
> I thought
On 9/19/19 6:18 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> On 9/19/19 3:48 PM, Tom Lane wrote:
>>> Seems like
>>> the error handling in jsonpath_gram.y could use some cleanup too
>>> ... although I don't think it's a task to tackle
Hi,
Attached is a draft for the PostgreSQL 12 RC1 press release. Please let
me know if you find any errors or notable omissions.
I'd also like to take this opportunity as a chance to say thank you to
everyone for your hard work to get PostgreSQL 12 to this point. I'm
personally very excited for w
On 9/25/19 6:50 AM, Sehrope Sarkuni wrote:
> The "Upgrading to PostgreSQL 12 RC 1" references v11 rather than v12:
>
> "To upgrade to PostgreSQL 11 RC 1 from Beta 4 or an earlier version of
> PostgreSQL 11, ..."
Thanks! Fixed attached,
Jonathan
PostgreSQL 12 RC 1 Released
===
On 9/25/19 8:21 AM, Erikjan Rijkers wrote:
> On 2019-09-25 13:08, Jonathan S. Katz wrote:
>> On 9/25/19 6:50 AM, Sehrope Sarkuni wrote:
>>> The "Upgrading to PostgreSQL 12 RC 1" references v11 rather than v12:
>>>
>>> "To upgrade to Post
On 9/28/19 12:00 PM, David Steele wrote:
> On 9/28/19 11:14 AM, Fujii Masao wrote:
>> On Sat, Sep 28, 2019 at 2:52 AM David Steele wrote:
>>
>>> The question for the old versions: is this something that should be
>>> fixed in the code or in the documentation?
>>>
>>> My vote is to make this explic
On 3/17/19 3:13 AM, Alexander Korotkov wrote:
> On Sat, Mar 16, 2019 at 9:39 PM Pavel Stehule wrote:
>> so 16. 3. 2019 v 10:36 odesílatel Alexander Korotkov
>> napsal:
>>>
>>> On Thu, Mar 14, 2019 at 12:07 PM Alexander Korotkov
>>> wrote:
On Sun, Mar 10, 2019 at 1:51 PM Alexander Korotkov
On 3/17/19 12:55 PM, Alexander Korotkov wrote:
>
>> However, when I did something a little more complex, like the below:
>>
>> SELECT count(*)
>> FROM news_feed
>> WHERE data @? '$.length ? (@ < 150)';
>>
>> SELECT count(*)
>> FROM news_feed
>> WHERE data @? '$.content ? (@ like_regex "^Start")';
On 3/17/19 1:02 PM, Alexander Korotkov wrote:
>
> Thank you for the explanation. Is it jsonb_ops or jsonb_path_ops?
I just used "USING gin(col)" so jsonb_ops.
Thanks,
Jonathan
signature.asc
Description: OpenPGP digital signature
On 3/17/19 1:14 PM, Alexander Korotkov wrote:
> On Sun, Mar 17, 2019 at 8:06 PM Jonathan S. Katz wrote:
>> On 3/17/19 1:02 PM, Alexander Korotkov wrote:
>>>
>>> Thank you for the explanation. Is it jsonb_ops or jsonb_path_ops?
>>
>> I just used "U
On 3/20/19 2:08 PM, Alvaro Herrera wrote:
> On 2019-Mar-20, Euler Taveira wrote:
>
>> Em qua, 20 de mar de 2019 às 14:57, Tom Lane escreveu:
>>>
>>> We managed to get rid of createlang and droplang in v10, and there
>>> hasn't been that much push-back about it. So maybe there could be
>>> a move
On 3/20/19 2:11 PM, Tom Lane wrote:
> "Fred .Flintstone" writes:
>> Even just creating symlinks would be a welcome change.
>> So the real binary is pg_foo and foo is a symoblic link that points to
>> pg_foo.
>> Then at least I can type pg_ and use tab auto-completion to find
>> everything related
On 3/20/19 3:19 PM, Andres Freund wrote:
> Hi,
>
> On 2019-03-20 15:15:02 -0400, Jonathan S. Katz wrote:
>> If we are evaluating this whole symlink / renaming thing, there could be
>> arguments for a "pgsql" alias to psql (or vice versa), but I don't think
>
On 7/22/19 3:20 PM, Andrew Dunstan wrote:
>
> On 7/22/19 3:15 PM, Tom Lane wrote:
>>
>> Frankly, this episode makes me wonder whether changing the default is
>> even a good idea at this point. People who care about security have
>> already set up their processes to select a useful-to-them auth op
Buffer Encryption
==
We will use AES-CBC for buffer encryption. We will add key id (4byte)
>>>
>>> I think we might want to use CTR for this, and will post after this.
>
> Not sure if I missed this post or not (as several people mentioned, it
> is easy to get lost in th
Hi,
Before my reply, I wanted to say that I've been lurking on this thread
for a bit as I've tried to better inform myself on encryption at rest
and how it will apply to what we want to build. I actually built a
(poor) prototype in Python of the key management system that Joe &
Masahiko both laid
On 8/2/19 3:21 PM, Tom Lane wrote:
> See
> https://git.postgresql.org/pg/commitdiff/082c9f5f761ced18a6f014f2638096f6a8228164
>
> Please send comments/corrections before Sunday.
While working on the PR, I noticed this line:
"This fixes a regression introduced in June's minor releases..."
Perhaps
On 8/4/19 10:52 AM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> Perhaps instead of "June" it could be the specific version number (which
>> could cause some pain with the back branching?) or the "2019-06-20" release?
>
> Putting in all th
On 8/4/19 11:08 AM, Jonathan S. Katz wrote:
> On 8/4/19 10:52 AM, Tom Lane wrote:
>> "Jonathan S. Katz" writes:
>>> Perhaps instead of "June" it could be the specific version number (which
>>> could cause some pain with the back branching?) or the
Hi,
On 8/6/19 3:01 PM, Bruce Momjian wrote:
> On Tue, Aug 6, 2019 at 01:55:38PM -0400, Bruce Momjian wrote:
>> CTR mode creates a bit stream for the first 16 bytes with nonce of
>> (segment_number, counter = 0), and the next 16 bytes with
>> (segment_number, counter = 1), etc. We only XOR using
On 8/8/19 2:15 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> On 2019-Aug-04, Jonathan S. Katz wrote:
>>> * Ensure that partition key columns will not be dropped as the result of an
>>> "indirect drop," such as from a cascade from dropping the key column
On 8/8/19 2:40 PM, Alvaro Herrera wrote:
> On 2019-Aug-08, Jonathan S. Katz wrote:
>
>> I modified the copy of the announcement on the website to include the
>> pg_upgrade option.
>>
>> https://www.postgresql.org/about/news/1960/
>
> Ooh, had I thought you
On 8/8/19 2:45 PM, Alvaro Herrera wrote:
> On 2019-Aug-08, Jonathan S. Katz wrote:
>
>> On 8/8/19 2:40 PM, Alvaro Herrera wrote:
>>> On 2019-Aug-08, Jonathan S. Katz wrote:
>>>
>>>> I modified the copy of the announcement on the website to include t
On 8/9/19 11:51 AM, Jeff Davis wrote:
> On Fri, 2019-08-09 at 09:28 -0400, Stephen Frost wrote:
>> Having an 'any' option, as mentioned before, could be an alternative
>> though.
>
> ...
>
>> I agree with the point that there isn't any guarantee that it'll
>> always
>> be clear-cut as to which of
On 8/9/19 7:54 PM, Jeff Davis wrote:
> On Sat, 2019-08-10 at 00:17 +0300, Heikki Linnakangas wrote:
>> This is a multi-dimensional problem. "channel_binding=require" is
>> one
>> way to prevent MITM attacks, but sslmode=verify-ca is another. (Does
>> Kerberos also prevent MITM?) Or you might want
On 8/11/19 1:00 PM, Peter Eisentraut wrote:
> On 2019-08-09 23:56, Jeff Davis wrote:
>> 1. Hierarchical semantics, where you specify the least-secure
>> acceptable method:
>>
>> password_protocol = {any,md5,scram-sha-256,scram-sha-256-plus}
>
> What would the hierarchy be if scram-sha-512 and sc
On 8/11/19 3:56 PM, Peter Eisentraut wrote:
> On 2019-08-11 21:46, Jonathan S. Katz wrote:
>> On 8/11/19 1:00 PM, Peter Eisentraut wrote:
>>> On 2019-08-09 23:56, Jeff Davis wrote:
>>>> 1. Hierarchical semantics, where you specify the least
On 8/13/19 12:25 PM, Jeff Davis wrote:
> On Tue, 2019-08-13 at 11:56 +0900, Michael Paquier wrote:
>> I tend to prefer #2 as well and that's the kind of approach we were
>> tending to agree on when we discussed this issue during the v11 beta
>> for the downgrade issues with libpq. And as you say e
On 8/13/19 6:25 PM, Jeff Davis wrote:
> On Tue, 2019-08-13 at 16:51 -0400, Jonathan S. Katz wrote:
>> Alternatively, we could combine 2 & 3, e.g.:
>>
>> channel_binding = {disable|prefer|require}
>>
>> # comma-separated list of protocols that are ok to t
On 8/15/19 9:28 PM, Stephen Frost wrote:
> Greetings,
>
> * Jeff Davis (pg...@j-davis.com) wrote:
>> On Wed, 2019-08-14 at 11:38 +0900, Michael Paquier wrote:
>>> What I got in mind was a comma-separated list of authorized protocols
>>> which can be specified as a connection parameter, which exten
On 5/11/19 4:33 PM, Bruce Momjian wrote:
> I have posted a draft copy of the PG 12 release notes here:
>
> http://momjian.us/pgsql_docs/release-12.html
>
> They are committed to git. It includes links to the main docs, where
> appropriate. Our official developer docs will rebuild in a few
On 9/2/19 1:37 PM, Andrey Borodin wrote:
>
>
>> 2 сент. 2019 г., в 22:02, Jonathan S. Katz написал(а):
>>
>>
>> Attached is a patch proposing items for the major items section. This is
>> working off of the ongoing draft of the press release[1]. Feedback
>
On 5/12/19 11:42 PM, Bruce Momjian wrote:
> On Sun, May 12, 2019 at 10:49:07AM -0400, Jonathan Katz wrote:
>> Hi Bruce,
>>
>> On 5/11/19 4:33 PM, Bruce Momjian wrote:
>>> I have posted a draft copy of the PG 12 release notes here:
>>>
>>> http://momjian.us/pgsql_docs/release-12.html
>>>
>>> The
Hi Tom,
> On Jan 2, 2018, at 7:54 PM, Tom Lane wrote:
>
> Now that the January fest has nominally started, we need somebody
> to act as CF manager. Any volunteers?
>
> (If someone already did volunteer and I missed it, my apologies.)
While this will not help for the immediate problem, after r
Hi,
Attached is a draft of the press release for the update release going
out on 2010-11-14. Please provide feedback, particularly on the
technical accuracy of the statements.
Thanks!
Jonathan
2019-05-09 Cumulative Update Release
The PostgreSQL Global Develo
On 11/14/19 7:46 AM, Geoff Winkless wrote:
> On Tue, 12 Nov 2019 at 22:17, Jonathan S. Katz wrote:
>> Attached is a draft of the press release for the update release going
>> out on 2010-11-14. Please provide feedback, particularly on the
>> technical accuracy of the
On 4/8/19 8:19 AM, Peter Eisentraut wrote:
> On 2019-04-08 13:52, Andrew Dunstan wrote:
>> Yeah, if we're not going to do it now we should announce that we will
>> do it in the next release.
>
> Targeting PG13 seems reasonable.
Counter-argument: SCRAM has been available for 2 years since 10 featu
On 4/8/19 8:49 AM, Magnus Hagander wrote:
> On Mon, Apr 8, 2019 at 2:38 PM Jonathan S. Katz <mailto:jk...@postgresql.org>> wrote:
> Counter-argument: SCRAM has been available for 2 years since 10 feature
> freeze, there has been a lot of time already given to implement
On 4/8/19 10:08 AM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> On 4/8/19 8:49 AM, Magnus Hagander wrote:
>>> I think the real question is, is it OK to give them basically 5months
>>> warning, by right now saying if you don't have a release out in 6
On 4/8/19 2:28 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2019-04-08 13:34:12 -0400, Alvaro Herrera wrote:
>>> I'm not sure I understand all this talk about deferring changing the
>>> default to pg13. AFAICS only a few fringe drivers are missing support;
>>> not changing in pg12 means we'r
On 4/8/19 4:10 PM, Alvaro Herrera wrote:
> On 2019-Apr-08, Dave Cramer wrote:
>
>> On Mon, 8 Apr 2019 at 16:07, Alvaro Herrera
>> wrote:
>
>>> I meant an exception to the common situation that SCRAM-SHA-256 is
>>> supported and shipped in stable releases of each driver. The wiki here
>>> still
On 4/8/19 4:20 PM, Alvaro Herrera wrote:
> On 2019-Apr-08, Jonathan S. Katz wrote:
>
>> On 4/8/19 4:10 PM, Alvaro Herrera wrote:
>
>>> I wonder why we have two pages
>>> https://wiki.postgresql.org/wiki/Client_Libraries
>>> https://wiki.postgresql.org/
On 4/8/19 6:10 PM, Jonathan S. Katz wrote:
> On 4/8/19 4:20 PM, Alvaro Herrera wrote:
>> On 2019-Apr-08, Jonathan S. Katz wrote:
>>
>>> On 4/8/19 4:10 PM, Alvaro Herrera wrote:
>>
>>>> I wonder why we have two pages
>>>> https:
On 5/3/19 6:29 PM, Tom Lane wrote:
> See
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8b3bce2017b15e05f000c3c5947653a3e2c5a29f
>
> Please send any corrections by Sunday.
Attached is a draft of the press release to go out. Please let me know
if there are any inaccuracies
1 - 100 of 684 matches
Mail list logo
