Re: PG 18 release notes draft committed - Mailing list pgsql-hackers

Hi,

On Fri, May 2, 2025 at 11:44 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have committd the first draft of the PG 18 release notes.  The item
> count looks strong:
>
>         release-7.4:  263
>         release-8.0:  230
>         release-8.1:  174
>         release-8.2:  215
>         release-8.3:  214
>         release-8.4:  314
>         release-9.0:  237
>         release-9.1:  203
>         release-9.2:  238
>         release-9.3:  177
>         release-9.4:  211
>         release-9.5:  193
>         release-9.6:  214
>         release-10:   189
>         release-11:   170
>         release-12:   180
>         release-13:   178
>         release-14:   220
>         release-15:   184
>         release-16:   206
>         release-17:   182
>         release-18:   209
>
> I will continue improving it until beta 1, and until the final release.
> I will probably add markup in 1-3 weeks.  Let the feedback begin.  ;-)

Thanks for your work!

> Add REJECT_LIMIT to control the number of invalid rows COPY IN can ignore (Atsushi Torikoshi)

Since REJECT_LIMIT cannot be used with COPY IN but can be used with
COPY FROM, I think "IN" should be "FROM".

  =# COPY t1 TO '/tmp/a' WITH (REJECT_LIMIT 3);
  ERROR:  COPY REJECT_LIMIT requires ON_ERROR to be set to IGNORE
  =# COPY t1 TO '/tmp/a' WITH ( ON_ERROR ignore, REJECT_LIMIT 3);
  ERROR:  COPY ON_ERROR cannot be used with COPY TO
  LINE 1: COPY t1 to '/tmp/a' WITH (ON_ERROR ignore, REJECT_LIMIT 3);


> This is active when ON_ERROR = 'ignore'.

As a non-native English speaker, I may be misunderstanding this, but
the word "active" might suggest that REJECT_LIMIT always takes effect
by default, causing the COPY operation to stop after a certain number
of errors.
However, in reality, REJECT_LIMIT does not have any effect by default
— unless explicitly set, there is no limit on the number of rows that
can be skipped when ON_ERROR is set to ignore.
To avoid this potential confusion, a phrasing like:

  This option must be used with ON_ERROR ignore.

might be clearer.

Also, in the v17 release notes, COPY option values are not enclosed in
single quotes but written in <literal> tag.
For consistency, it might be better to follow the same style in the
v18 notes as well.

  -- https://www.postgresql.org/docs/current/release-17.html
  Add new COPY option ON_ERROR ignore to discard error rows
  The default behavior is ON_ERROR stop


> Add COPY log_verbosity level "silent" to suppress all log output (Atsushi Torikoshi)

Similarly, in the v17 release notes, the log_verbosity option was
written in uppercase (LOG_VERBOSITY).
For consistency, it may be preferable to use the same case formatting
in this entry as well.

  -- https://www.postgresql.org/docs/current/release-17.html
  Add new COPY option LOG_VERBOSITY which reports COPY FROM ignored error rows

Also, the phrase "suppress all log output" may be slightly misleading.
Even with log_verbosity = 'silent', COPY still outputs logs — it only
suppresses log messages related to skipped rows when ON_ERROR ignore
is used.
It might help to clarify this nuance to avoid confusion.
For example, how about "Add COPY LOG_VERBOSITY silent to suppress logs
related to skipped rows"?


> Add on_error and log_verbosity options to file_fdw (Atsushi Torikoshi)
> Add REJECT_LIMIT to control the number of invalid rows file_fdw can ignore (Atsushi Torikoshi)
> This is active when ON_ERROR = 'ignore'.

The case of option names for file_fdw is inconsistent — some are
lowercase (on_error, log_verbosity), while others use uppercase
(REJECT_LIMIT, ON_ERROR).
For consistency, it might be better to standardize the option names
throughout the release notes.
Since the file_fdw documentation consistently uses lowercase for all
options, using lowercase in the release notes as well might feel more
natural.


--
Regards,
Atsushi Torikoshi