Re: PG 13 release notes, first draft

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 13 release notes, first draft
Date: 2020-05-07 16:38:41
Message-ID: 20200507163841.GM3649@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 7, 2020 at 11:30:40PM +0900, Amit Langote wrote:
> On Thu, May 7, 2020 at 11:12 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Well, her name was there already for a later commit that was not
> > backpatched, so I just moved her name earlier. The fact that her name
> > was moved earlier because of something that was backpatched is
> > inconsistent, but I don't know enough about the work that went into the
> > item to comment on that. I will need someone to tell me, of the commits
> > that only appear in PG 13, what should be the name order.
>
> Sorry, I misremembered that the patch to make default partition
> pruning more aggressive was not backpatched, because I thought at the
> time that the patch had turned somewhat complex, but indeed it was
> backpatched; in 11.5 release notes:
>
> Prune a partitioned table's default partition (that is, avoid
> uselessly scanning it) in more cases (Yuzuko Hosoya)
>
> Sorry for the noise.
>
> I think it's okay for her name to appear first even considering the
> commits that only appear in PG 13, because my role was mainly
> reviewing the work and perhaps posting an updated version of her
> patch.

OK, confirmed, thanks.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-05-07 17:06:46 Re: PG 13 release notes, first draft
Previous Message Peter Geoghegan 2020-05-07 16:18:52 Re: Should smgrdounlink() be removed?