Re: [PATCH] Add error hints for invalid COPY options

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Sugamoto Shinya <shinya34892(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Add error hints for invalid COPY options
Date: 2025-11-24 19:56:34
Message-ID: CAD21AoCHJjFM4ts=E+_4+BUR=ssB0QP_JzdNXWe+L4adzWOOmQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sat, Nov 22, 2025 at 8:33 PM Sugamoto Shinya <shinya34892(at)gmail(dot)com> wrote:
>
> Hi,
>
> This patch improves the user experience when working with COPY commands by
> adding helpful error hints for invalid options.
>
> Currently, when users make typos in COPY option names or values, they receive
> a generic error message without guidance on what went wrong. This patch adds
> two types of hints:
>
> 1. For invalid option names: suggests the closest matching valid option using
> the ClosestMatch algorithm (e.g., "foramt" → "Perhaps you meant 'format'")
>
> 2. For invalid option values: lists all valid values when the set is small
> (e.g., for format, on_error, log_verbosity options)
>
> This follows the pattern already used elsewhere in PostgreSQL for providing
> helpful error hints to users.

Given we have 15 COPY options now, it sounds like a reasonable idea.

One concern about the patch is that when adding a new COPY option, we
could miss updating valid_copy_options list, resulting in providing a
wrong suggestion. I think we can consider refactoring the COPY option
handling so that we check the given option is a valid name or not by
checking valid_copy_options array and then process the option value.

> Additionally, this patch corrects a misleading comment for the
> convert_selectively option. The comment stated it was "not-accessible-from-SQL",
> but actualy it has been accessible from SQL due to PostgreSQL's generic option parser.
> The updated comment clarifies that while technically accessible, it's intended for
> internal use and not recommended for end-user use due to potential data loss.

Hmm, I'm not sure the proposed comment improves the clarification.
It's essentially non-accessible from SQL since we cannot provide a
valid value for convert_selectively from SQL commands.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2025-11-24 19:59:33 Re: another autovacuum scheduling thread
Previous Message Robert Haas 2025-11-24 19:52:09 Re: get rid of Pointer type, mostly