Обсуждение: 2020-02-13 Press Release Draft

Hi,

Attached is a draft for the 2020-02-13 press release. I would appreciate
any review for accuracy, notable omissions, and the inevitable typos I
tend to have on drafts (even though I do run it through a spell
checker). There were over 75 fixes, so paring the list down was a bit
tricky, and I tried to focus on things that would have noticeable user
impact.

As noted in other threads, this is the EOL release for 9.4. In a
departure from the past, I tried to give a bit of a "tribute" to 9.4 by
listing some of the major / impactful features that were introduced, the
thought process being that we should celebrate the history of PostgreSQL
and also look at how far we've come in 5 years. If we feel this does not
make sense, I'm happy to remove it.

While I'll accept feedback up until time of release, please try to have
it in no later than 2020-02-13 0:00 UTC :)

Thanks,

Jonathan

On 2020-02-10 17:46, Jonathan S. Katz wrote:
> Hi,
> 
> Attached is a draft for the 2020-02-13 press release. I would 
> appreciate

A small typo:

'many of which have receive improvements'   should be
'many of which have received improvements'

On 2/10/20 11:55 AM, Erik Rijkers wrote:
> On 2020-02-10 17:46, Jonathan S. Katz wrote:
>> Hi,
>>
>> Attached is a draft for the 2020-02-13 press release. I would appreciate
>
> A small typo:
>
> 'many of which have receive improvements'   should be
> 'many of which have received improvements'

Fixed on my local copy. Thanks!

Jonathan

On 2/10/20 12:03 PM, Sehrope Sarkuni wrote:
> Typo in 9.4 retirement message:
>
> s/is it time to retire/it is time to retire/

Heh, we definitely don't want that to be a question :)

Fixed on my local copy, thanks!

Jonathan

On 2020-Feb-10, Jonathan S. Katz wrote:

> * Several figures for GSSAPI support, including having libpq accept all
> GSS-related connection parameters even if the GSSAPI code is not compiled in.

"figures"?

> If you had previously executed `TRUNCATE .. CASCADE` on a sub-partition of a
> partitioned table, and the partitioned table has a foreign-key reference from
> another table, you will have to run the `TRUNCATE` on the other table as well.
> The issue that caused this is fixed in this release, but you will have to
> perform this step to ensure all of your data is cleaned up.

I'm unsure about the "will" in the "you will have to run the TRUNCATE".
If the table is truncated then reloading, then the truncation might be
optional.  I would change the "will" to "may".  At the same time I
wonder if it would make sense to provide a query that would return any
rows violating such constraints; if empty then there's no need to
truncate.  On the other hand, if not empty, perhaps we can suggest to
delete just those rows rather than truncating everything.  Perhaps we
can quote ri_triggers.c's RI_Initial_Check,

    /*----------
     * The query string built is:
     *  SELECT fk.keycols FROM [ONLY] relname fk
     *   LEFT OUTER JOIN [ONLY] pkrelname pk
     *   ON (pk.pkkeycol1=fk.keycol1 [AND ...])
     *   WHERE pk.pkkeycol1 IS NULL AND
     * For MATCH SIMPLE:
     *   (fk.keycol1 IS NOT NULL [AND ...])
     * For MATCH FULL:
     *   (fk.keycol1 IS NOT NULL [OR ...])
     *
     * We attach COLLATE clauses to the operators when comparing columns
     * that have different collations.
     *----------
     */

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 2/10/20 12:23 PM, Alvaro Herrera wrote:
> On 2020-Feb-10, Jonathan S. Katz wrote:
>
>> * Several figures for GSSAPI support, including having libpq accept all
>> GSS-related connection parameters even if the GSSAPI code is not compiled in.
>
> "figures"?

"figures" I have a typo ;) Fixed to "fixes"

>
>> If you had previously executed `TRUNCATE .. CASCADE` on a sub-partition of a
>> partitioned table, and the partitioned table has a foreign-key reference from
>> another table, you will have to run the `TRUNCATE` on the other table as well.
>> The issue that caused this is fixed in this release, but you will have to
>> perform this step to ensure all of your data is cleaned up.
>
> I'm unsure about the "will" in the "you will have to run the TRUNCATE".
> If the table is truncated then reloading, then the truncation might be
> optional.  I would change the "will" to "may".

Changed. And...

> At the same time I
> wonder if it would make sense to provide a query that would return any
> rows violating such constraints; if empty then there's no need to
> truncate.  On the other hand, if not empty, perhaps we can suggest to
> delete just those rows rather than truncating everything.  Perhaps we
> can quote ri_triggers.c's RI_Initial_Check,
>
>     /*----------
>      * The query string built is:
>      *  SELECT fk.keycols FROM [ONLY] relname fk
>      *   LEFT OUTER JOIN [ONLY] pkrelname pk
>      *   ON (pk.pkkeycol1=fk.keycol1 [AND ...])
>      *   WHERE pk.pkkeycol1 IS NULL AND
>      * For MATCH SIMPLE:
>      *   (fk.keycol1 IS NOT NULL [AND ...])
>      * For MATCH FULL:
>      *   (fk.keycol1 IS NOT NULL [OR ...])
>      *
>      * We attach COLLATE clauses to the operators when comparing columns
>      * that have different collations.
>      *----------
>      */

...yeah, I like that approach, especially if it's "may" instead of
"will" -- we should give our users the tools to determine if they have
to do anything. Should we just give the base base?

    SELECT
        fk.keycol
    FROM
        relname fk
        LEFT OUTER JOIN pkrelname pk ON pk.pkkeycol = fk.keycol
    WHERE
        pk.pkkeycol IS NULL
        AND fk.keycol IS NOT NULL;

RE TRUNCATE vs. DELETE, we should present the option ("TRUNCATE" is the
easiest route, but you may opt to "DELETE" instead due to having
replaced the data)

Thanks,

Jonathan

Em 10/02/2020 13:46, Jonathan S. Katz escreveu:
> Hi,
>
> Attached is a draft for the 2020-02-13 press release. I would appreciate
> any review for accuracy, notable omissions, and the inevitable typos I
> tend to have on drafts (even though I do run it through a spell
> checker). There were over 75 fixes, so paring the list down was a bit
> tricky, and I tried to focus on things that would have noticeable user
> impact.
>
> As noted in other threads, this is the EOL release for 9.4. In a
> departure from the past, I tried to give a bit of a "tribute" to 9.4 by
> listing some of the major / impactful features that were introduced, the
> thought process being that we should celebrate the history of PostgreSQL
> and also look at how far we've come in 5 years. If we feel this does not
> make sense, I'm happy to remove it.
>
> While I'll accept feedback up until time of release, please try to have
> it in no later than 2020-02-13 0:00 UTC :)
>
> Thanks,
>
> Jonathan

s/Several fix for query planner errors/Several fixes for query planner 
errors/

On 2/10/20 12:55 PM, Luís Roberto Weck wrote:
> Em 10/02/2020 13:46, Jonathan S. Katz escreveu:
>> Hi,
>>
>> Attached is a draft for the 2020-02-13 press release. I would appreciate
>> any review for accuracy, notable omissions, and the inevitable typos I
>> tend to have on drafts (even though I do run it through a spell
>> checker). There were over 75 fixes, so paring the list down was a bit
>> tricky, and I tried to focus on things that would have noticeable user
>> impact.
>>
>> As noted in other threads, this is the EOL release for 9.4. In a
>> departure from the past, I tried to give a bit of a "tribute" to 9.4 by
>> listing some of the major / impactful features that were introduced, the
>> thought process being that we should celebrate the history of PostgreSQL
>> and also look at how far we've come in 5 years. If we feel this does not
>> make sense, I'm happy to remove it.
>>
>> While I'll accept feedback up until time of release, please try to have
>> it in no later than 2020-02-13 0:00 UTC :)
>>
>> Thanks,
>>
>> Jonathan
>
> s/Several fix for query planner errors/Several fixes for query planner
> errors/

Thanks! Fixed applied.

Here is the latest canonical copy. I also incorporated some of Alvaro's
suggestions, though when trying to add the query I found the explanation
becoming too long. Perhaps it might make an interesting blog post? ;)

Please let me know if there are any more suggestions/changes before the
release (which is rapidly approaching).

Thanks!

Jonathan