Re: pgsql: docs: fist draft version of the PG 12 release notes

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: docs: fist draft version of the PG 12 release notes
Date: 2019-05-08 20:20:40
Message-ID: 20190508202040.GA11001@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On 2019-May-06, Bruce Momjian wrote:

> docs: fist draft version of the PG 12 release notes

Hello, thanks for doing this work once again.

Typo in surname: "Golgov" is Dolgov.

This entry:
Allow foreign keys to reference partitioned tables (Alvaro Herrera)
says "LIMITATIONS?" but I don't think there are any of significance.
You can now reference unique/PKs that appear in partitioned tables,
period. Just remove the LIMITATIONS should do it ;-)

This is a bit misleading:

Remove the special behavior of OID columns (Andres Freund, John Naylor)

Previously, a normally-invisible OID column could be specified
during table creation using WITH OIDS; that ability has been
removed. Columns can still be explicitly specified as type OID.
pg_dump and pg_upgrade operations on databases using WITH OIDS will
need adjustment. Many system tables now have an 'oid' column that
will be expanded with SELECT * by default.

"databases using WITH OIDS will need adjustment". In reality, many
databases carried over by pg_upgrade from old versions will need
adjustment, since old tables had oids by default. This could be more
troublesome than the current wording suggest. Maybe use something like
"... operations on databases containing tables with the oid system
column will need adjustment", so that users have to research whether
they have them or not. If we only say WITH OIDS then people will think
they've never used that clause so they must not worry.

Specify a range of oids (9000-9999) to be used for external
extensions (Andres Freund)

I'm not sure that "specify" is the right verb to use for this one.
Nothing better comes to mind ATM ...

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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tatsuo Ishii 2019-05-08 22:58:00 Re: pgsql: docs: fist draft version of the PG 12 release notes
Previous Message Peter Geoghegan 2019-05-08 19:49:02 pgsql: Remove obsolete nbtree split REDO routine comment.