Re: First draft of back-branch release notes is done

See
https://git.postgresql.org/pg/commitdiff/082c9f5f761ced18a6f014f2638096f6a8228164

Please send comments/corrections before Sunday.

regards, tom lane

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 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?

Thanks,

Jonathan

"Jonathan S. Katz" <jkatz(at)postgresql(dot)org> 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 the version numbers seems like a mess, but specifying
2019-06-20 would work --- or we could say "the most recent" minor
releases?

regards, tom lane

On 8/4/19 10:52 AM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz(at)postgresql(dot)org> 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 the version numbers seems like a mess, but specifying
> 2019-06-20 would work --- or we could say "the most recent" minor
> releases?

That or "previous minor release" would seem to work.

(In the PR I'm putting in the versions it was introduced but we have the
luxury of only having one PR.)

Jonathan

On 8/4/19 11:08 AM, Jonathan S. Katz wrote:
> On 8/4/19 10:52 AM, Tom Lane wrote:
>> "Jonathan S. Katz" <jkatz(at)postgresql(dot)org> 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 the version numbers seems like a mess, but specifying
>> 2019-06-20 would work --- or we could say "the most recent" minor
>> releases?
>
> That or "previous minor release" would seem to work.
>
> (In the PR I'm putting in the versions it was introduced but we have the
> luxury of only having one PR.)

Attached is the first draft of the PR.

Jonathan

I realize that this has now been sent, but I wanted to comment on one
item:

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's data
> type (e.g. a custom data type). This fix is applied only to newly created
> partitioned tables: if you believe you have an affected partition table (e.g.
> one where the partition key uses a custom data type), you will need to
> create a new table and move your data into it.

Hmm, if I have this problem, I can pg_upgrade and the new database will
have correct dependencies, right? For some people, doing that might be
easier than creating and reloading large tables.

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

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> 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's data
>> type (e.g. a custom data type). This fix is applied only to newly created
>> partitioned tables: if you believe you have an affected partition table (e.g.
>> one where the partition key uses a custom data type), you will need to
>> create a new table and move your data into it.

> Hmm, if I have this problem, I can pg_upgrade and the new database will
> have correct dependencies, right? For some people, doing that might be
> easier than creating and reloading large tables.

Yeah, that should work.

regards, tom lane

On 8/8/19 2:15 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> 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's data
>>> type (e.g. a custom data type). This fix is applied only to newly created
>>> partitioned tables: if you believe you have an affected partition table (e.g.
>>> one where the partition key uses a custom data type), you will need to
>>> create a new table and move your data into it.
>
>> Hmm, if I have this problem, I can pg_upgrade and the new database will
>> have correct dependencies, right? For some people, doing that might be
>> easier than creating and reloading large tables.
>
> Yeah, that should work.

I modified the copy of the announcement on the website to include the
pg_upgrade option.

https://www.postgresql.org/about/news/1960/

Thanks!

Jonathan

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 were going to do that, I would have told you
about the item ending in a comma :-)

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

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 were going to do that, I would have told you
> about the item ending in a comma :-)

:) I made a quick modification and opted for an "either" at the
beginning of that clause and a capitalized "OR" towards the end.

Jonathan

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 the
> >> pg_upgrade option.
> >>
> >> https://www.postgresql.org/about/news/1960/
> >
> > Ooh, had I thought you were going to do that, I would have told you
> > about the item ending in a comma :-)
>
> :) I made a quick modification and opted for an "either" at the
> beginning of that clause and a capitalized "OR" towards the end.

Oh, heh ... I was thinking of this line:

Fix for multi-column foreign keys when rebuilding a foreign key constraint,

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

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 the
>>>> pg_upgrade option.
>>>>
>>>> https://www.postgresql.org/about/news/1960/
>>>
>>> Ooh, had I thought you were going to do that, I would have told you
>>> about the item ending in a comma :-)
>>
>> :) I made a quick modification and opted for an "either" at the
>> beginning of that clause and a capitalized "OR" towards the end.
>
> Oh, heh ... I was thinking of this line:
>
> Fix for multi-column foreign keys when rebuilding a foreign key constraint,

Oh oops. Fixed :) Thanks,

Jonathan