Thread: PostgreSQL 12 Press Release - First Draft
Hi, Attached is a first draft of the press release for PostgreSQL 12. Feedback welcome (more below), though I ask feedback to be provided no later than September 6, 2019. A few comments for context: Using the release notes[1], 12 beta 1 release[2], and miscellaneous feedback as a guide, there seemed to be roughly five major feature groups: - Overall Performance Improvements (focuses on the indexing + partitioning work, MCV stats) - Enhancements to SQL Conformance & Functionality (SQL/JSON, inlined CTEs, generated columns) - Internationalization (ICU case insensitivity) - Authentication (GSSAPI encryption, LDAP discovery, clientcert=verify-full) - Administrative (REINDEX CONCURRENTLY, pg_checksums) I mentioned pluggable storage interface in it but did not elaborate in too much detail. I am a huge fan of this effort, but for the typical PG12 user, we may not want to elaborate too much on it in the general press release. Feedback I'm looking for: - Grammar / typos / awkward wording (I did already catch "party of a query" :) - Checks for technical accuracy - Glaring feature omissions - Features that should be downplayed - User testimonials / quotes Thanks! Jonathan [1] https://www.postgresql.org/docs/12/release-12.html [2] https://www.postgresql.org/about/news/1943/
Attachment
On 2019-08-21 22:43, Jonathan S. Katz wrote: > Hi, > > Attached is a first draft of the press release for PostgreSQL 12. A few typos: 'PostgreSQL 12 also improvements the performance of' should be 'PostgreSQL 12 also improves the performance when' 'with blocking any queries' should be (I think) 'without blocking any queries' 'write-head-log' should be 'write-ahead-log' 'that can be computed its value from other columns' 'that can compute its value from other columns' and something is not quite right about the sentence containing: 'LDAP servers using if it' but I can't figure out what it should be. thanks, Erik Rijkers
On 8/21/19 5:02 PM, Erik Rijkers wrote: > On 2019-08-21 22:43, Jonathan S. Katz wrote: >> Hi, >> >> Attached is a first draft of the press release for PostgreSQL 12. > > A few typos: > > 'PostgreSQL 12 also improvements the performance of' should be > 'PostgreSQL 12 also improves the performance when' > > 'with blocking any queries' should be (I think) > 'without blocking any queries' > > 'write-head-log' should be > 'write-ahead-log' > > 'that can be computed its value from other columns' > 'that can compute its value from other columns' > > and something is not quite right about the sentence containing: > 'LDAP servers using if it' > but I can't figure out what it should be. Thanks! I incorporated most of your suggestions in the updated copy. Jonathan
Attachment
——— “OSCon” should be “OSCON”, all uppercase. Source: https://conferences.oreilly.com/oscon/oscon-or ——— I would make two sentences of this: >PostgreSQL 12 also improves the performance of adding data to partitioned tables with "INSERT" and "COPY", and a new partition can now be attached to a table without blocking queries. …to this: >PostgreSQL 12 also improves the performance of adding data to partitioned tables with "INSERT" and “COPY”. And a new partition can now be attached to a table without blocking queries. ——— Shorten: >PostgreSQL 12 introduces the ability to run queries over JSON documents using JSON path expressions defined in the SQL/JSON standard. Additionally, certain JSON path expressions can utilize the existing indexing mechanisms for documents stored in the JSONB format to efficiently retrieve data. …to this: >PostgreSQL 12 introduces the ability to run queries over JSON documents using JSON path expressions defined in the SQL/JSON standard. Such queries may utilize the existing indexing mechanisms for documents stored in the JSONB format to efficiently retrieve data. ——— I would mention the SQL standard here (SQL:2003 as I recall). And drop the words “also” and “only". So this: >PostgreSQL 12 also introduces generated columns, which is a type of column that can be computed its value from other columns in the same table. Currently, PostgreSQL only supports "stored generated columns," where the computed value is stored on the disk. …becomes: >PostgreSQL 12 introduces "generated columns”. Defined in the SQL standard, this type of column computes its value from thevalues of other columns in the same table. Currently, PostgreSQL supports "stored generated columns," where the computed value is stored on the disk. ——— Your document looks good to me as-is. My only addition would be something about Just-In-Time (JIT) compiling and use of LLVMbecause: (a) JIT & LLVM are high-tech items that may catch the attention of some. So, good PR. (b) The feature provide significant improvements in performance to some. Something like (caveat, I am not an expert here): >Through the use of LLVM compiler technology, PostgreSQL 12 now enables by default the Just-In-Time (JIT) compiling of generatedcode. Longer-running CPU-intensive queries can see significant performance improvements. —Basil Bourque
Am 21.08.19 um 23:11 schrieb Jonathan S. Katz:
> On 8/21/19 5:02 PM, Erik Rijkers wrote:
>> On 2019-08-21 22:43, Jonathan S. Katz wrote:
>>> Hi,
>>>
>>> Attached is a first draft of the press release for PostgreSQL 12.
>>
>> A few typos:
>>
--8><------><8----
>> but I can't figure out what it should be.
>
> Thanks! I incorporated most of your suggestions in the updated copy.
Awesome work as usual, Jonathan!
My 2p:
- To me, a non-native speaker, this ("select") feels odd (although I see
what's meant!) in a text on a database:
"that only need to retrieve data from a select few"
- Okular doesn't display the 'distance operator (“”)' (but that might be
Okular, afterall)
- s/can be computed its value/can be computed/ (that's been mentioned
already, I think)
- I'd personally leave the "in PostgreSQL 12" out of "additional
security and functionality in PostgreSQL 12"
- s/an authentication client/an authenticating client/ ?
Cheers!
--
Gunnar "Nick" Bluth
DBA ELSTER
Extern im Auftrag der Hays AG
Tel: +49 911/991-4665
Mobil: +49 172/8853339
"Ceterum censeo SystemD esse delendam"
Attachment
On 2019-08-21 22:43, Jonathan S. Katz wrote: > - Administrative (REINDEX CONCURRENTLY, pg_checksums) Enhancements to progress tracking of various utility commands might fit in under this heading. Other than that, I don't see anything major to be added. The file you attached contains a confusing selection of non-ASCII characters such as curly quotes and non-breaking spaces. Nothing wrong with using those, of course, but it's not done consistently and looks gratuitous. You should look into cleaning that up so that this doesn't get messed up further by downstream processors of the press release. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi Everyone, On 8/25/19 5:01 AM, Peter Eisentraut wrote: > On 2019-08-21 22:43, Jonathan S. Katz wrote: >> - Administrative (REINDEX CONCURRENTLY, pg_checksums) > > Enhancements to progress tracking of various utility commands might fit > in under this heading. > > Other than that, I don't see anything major to be added. > > > The file you attached contains a confusing selection of non-ASCII > characters such as curly quotes and non-breaking spaces. Nothing wrong > with using those, of course, but it's not done consistently and looks > gratuitous. You should look into cleaning that up so that this doesn't > get messed up further by downstream processors of the press release. Thank you all for your feedback, it was incredibly helpful! I waited a few days before incorporating changes to try to limit the back-and-forth. Please see attached for the latest draft. I tried to move this closer to the final markdown version (e.g. to Peter's point above) though there is some additional formatting I will provide before the final one. Again, please keep your feedback coming through September 6, 2019 AOE[1]. I will let you know if there is an extension, of course :) Thanks! Jonathan [1] https://en.wikipedia.org/wiki/Anywhere_on_Earth
Attachment
On 9/2/19 11:19 AM, Jonathan S. Katz wrote: > Hi Everyone, > > On 8/25/19 5:01 AM, Peter Eisentraut wrote: >> >> The file you attached contains a confusing selection of non-ASCII >> characters such as curly quotes and non-breaking spaces. Nothing wrong >> with using those, of course, but it's not done consistently and looks >> gratuitous. You should look into cleaning that up so that this doesn't >> get messed up further by downstream processors of the press release. > > Please see attached for the latest draft. I tried to move this closer to > the final markdown version (e.g. to Peter's point above) though there is > some additional formatting I will provide before the final one. And no sooner do I say that do I find additional broken formatting. Please see attached with updates. Jonathan
Attachment
On 2019-09-02 17:36, Jonathan S. Katz wrote: > On 9/2/19 11:19 AM, Jonathan S. Katz wrote: >> Please see attached for the latest draft. I tried to move this closer >> to 'common-table expression' should be 'common table expression' If you really do prefer the hyphen there then it should also be in the other usage of 'Common table expressions' in this text, I think. 'most-common value' should be 'most common value' 'that build on the implementation of the SQL standard' Perhaps better: 'that build on the SQL standard' 'JSON path expressions' Perhaps better: 'JSON path expressions' And perhaps 'aka' should be fully written out 'also known as'. For us non-native speakers it takes a while before all these abbreviations become clear. I know it's taken me a few years before I decoded it :) thanks, Erik Rijkers
On 9/2/19 12:05 PM, Erik Rijkers wrote: > On 2019-09-02 17:36, Jonathan S. Katz wrote: >> On 9/2/19 11:19 AM, Jonathan S. Katz wrote: >>> Please see attached for the latest draft. I tried to move this closer to > > > 'common-table expression' should be > 'common table expression' > If you really do prefer the hyphen there then it should also be in the > other usage of 'Common table expressions' in this text, I think. You're correct, there should not be a hyphen there. > 'most-common value' should be > 'most common value' There seems to be a few ways of doing this; I had gone by what was documented in CREATE STATISTICS[1], so my preference is to leave it as is. > 'that build on the implementation of the SQL standard' Perhaps better: > 'that build on the SQL standard' I modified it with a different take. I think the goal is to capture that PostgreSQL continues to implement newer elements of the SQL standard. "Building on" could sound like that we are adding enhancements on top of the standard (which there are certainly cases where we do :) and I think the end goal is to capture that we are keeping up with the evolution of SQL. > 'JSON path expressions' Perhaps better: > 'JSON path expressions' The docs indicate there is a space[2] unless referring to the specific data type, so I would recommend leaving it as is. > And perhaps 'aka' should be fully written out 'also known as'. For us > non-native speakers it takes a while before all these abbreviations > become clear. I know it's taken me a few years before I decoded it :) I did a s/aka/also known as/ Thanks! Jonathan [1] https://www.postgresql.org/docs/12/sql-createstatistics.html [2] https://www.postgresql.org/docs/12/functions-json.html#FUNCTIONS-SQLJSON-PATH
Attachment
Hi Jonathan, On 02/09/2019 17:19, Jonathan S. Katz wrote: > Hi Everyone, > > Thank you all for your feedback, it was incredibly helpful! I waited a > few days before incorporating changes to try to limit the back-and-forth. > > Please see attached for the latest draft. I tried to move this closer to > the final markdown version (e.g. to Peter's point above) though there is > some additional formatting I will provide before the final one. > > Again, please keep your feedback coming through September 6, 2019 > AOE[1]. I will let you know if there is an extension, of course :) > > [...] > > # PostgreSQL 12 Released! I am not a native speaker but this sounds weird to me, shouldn't it say something like "is released" or "has been released"? > For a full list of features included in this release, please read the release notes, which can be found at: https://www.postgresql.org/docs/12/static/release-12.html The "/static" part of url should be removed IMHO, shorter url without redirect is always better both for humans and for indexing. -- Petr Jelinek 2ndQuadrant - PostgreSQL Solutions for the Enterprise https://www.2ndQuadrant.com/
On 9/3/19 2:11 AM, Petr Jelinek wrote: > Hi Jonathan, > > On 02/09/2019 17:19, Jonathan S. Katz wrote: >> Hi Everyone, >> >> Thank you all for your feedback, it was incredibly helpful! I waited a >> few days before incorporating changes to try to limit the back-and-forth. >> >> Please see attached for the latest draft. I tried to move this closer to >> the final markdown version (e.g. to Peter's point above) though there is >> some additional formatting I will provide before the final one. >> >> Again, please keep your feedback coming through September 6, 2019 >> AOE[1]. I will let you know if there is an extension, of course :) > >> [...] >> >> # PostgreSQL 12 Released! > > I am not a native speaker but this sounds weird to me, shouldn't it say > something like "is released" or "has been released"? The pattern we've traditionally followed has been to do just "Released"[1][2][3][4][5] including minor updates[6]. It is ok to say this in English -- it's a declarative statement and is something you often see in a headline, e.g. "PostgreSQL 12 Released! Millions Cheers!" (...which, if that formulation is true, it doesn't sound so bad to me :) If we want for a variation, I'd consider "is released" or "is now released" to avoid the passive voice. >> For a full list of features included in this release, please read the >> release notes, which can be found at: >> https://www.postgresql.org/docs/12/static/release-12.html > > The "/static" part of url should be removed IMHO, shorter url without > redirect is always better both for humans and for indexing. Yeah, that one is a mistake, and slightly embarrassing given I wrote the patch to make that redirect ;) Fixed attached. Thanks! Jonathan [1] https://www.postgresql.org/about/news/1894/ [2] https://www.postgresql.org/about/news/1786/ [3] https://www.postgresql.org/about/news/1703/ [4] https://www.postgresql.org/about/news/1481/ [5] https://www.postgresql.org/about/news/1415/ [6] https://www.postgresql.org/about/news/1960/
Attachment
On Tue, Sep 3, 2019 at 10:25 AM Jonathan S. Katz <jkatz@postgresql.org> wrote: > Fixed attached. Forgive me if this question has already been answered someplace, but has a release date been determined? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 9/3/19 10:27 AM, Robert Haas wrote: > On Tue, Sep 3, 2019 at 10:25 AM Jonathan S. Katz <jkatz@postgresql.org> wrote: >> Fixed attached. > > Forgive me if this question has already been answered someplace, but > has a release date been determined? No, but as there are a lot of moving pieces on the advocacy front, we try to be prepared as much in advance as possible. Timing-wise, we're working backwards from the typical aim of end-of-September. (Fun fact, on the roadmap[1] page we say Q3) Jonathan [1] https://www.postgresql.org/developer/roadmap/
Attachment
I see a placeholder quote. Can we help with a quote from Bruce Momjian in his role as a core team member of the PostgreSQLGlobal Development Group (or anyone else from EDB with a community role)? ______________________________________________________________________________________________ Glenn Rossman 914-623-8354 -----Original Message----- From: Jonathan S. Katz <jkatz@postgresql.org> Sent: Tuesday, September 03, 2019 11:03 AM To: Robert Haas <robertmhaas@gmail.com> Cc: Petr Jelinek <petr@2ndquadrant.com>; PostgreSQL Advocacy <pgsql-advocacy@lists.postgresql.org> Subject: Re: PostgreSQL 12 Press Release - First Draft On 9/3/19 10:27 AM, Robert Haas wrote: > On Tue, Sep 3, 2019 at 10:25 AM Jonathan S. Katz <jkatz@postgresql.org> wrote: >> Fixed attached. > > Forgive me if this question has already been answered someplace, but > has a release date been determined? No, but as there are a lot of moving pieces on the advocacy front, we try to be prepared as much in advance as possible.Timing-wise, we're working backwards from the typical aim of end-of-September. (Fun fact, on the roadmap[1] page we say Q3) Jonathan [1] https://www.postgresql.org/developer/roadmap/