Re: Fixes a typo in tablecmd

Xuneng Zhou <xunengzhou@gmail.com>

From: Xuneng Zhou <xunengzhou@gmail.com>
To: Chao Li <li.evan.chao@gmail.com>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-15T01:34:49Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix typo in tablecmds.c

Hi Chao,

On Mon, Dec 15, 2025 at 7:26 AM Chao Li <li.evan.chao@gmail.com> wrote:
>
> Hi Hackers,
>
> I noticed this while working on a patch with tablecmd:
>
> ```
> /*
> * If the table at either end of the constraint is partitioned, we need to
> * recurse and handle every unvalidate constraint that is a child of this
> * constraint.
> */
> ```
>
> Here “unvalidate” looks abnormal to me but not an obvious spelling error. Then I searched over the source tree, and found two similar occurrences:
>
> Also in tablecmd.c
> ```
>     /* an unvalidated constraint is no good */
> ```
>
> In pg_dump.c
> ```
>  /*
> * An unvalidated constraint needs to be dumped separately, so
> * that potentially-violating existing data is loaded before
> * the constraint.
> */
> ```
>
> Notice the difference: “unvalidate” vs “unvalidated”.
>
> Then I recalled that Tom referred to the online dictionary https://www.onelook.com for checking typo in discussion [1], and I checked with the web site. It shows that “unvalidate” is not found; and “unvalidated” has 3 matches and means “not confirmed as true yet”.
>
> So, I believe “unvalidate” is a typo, a “d” should be appended.
>
> [1] https://postgr.es/m/2118725.1762837193@sss.pgh.pa.us
>
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
>

Unvalidate does seem grammatically incorrect here. Unvalidated, though
uncommon, looks like a valid term for this usage. [1] [2]

[1] https://english.stackexchange.com/questions/58584/alternative-of-unvalidated
[2] https://books.google.com/ngrams/graph?content=unvalidated&year_start=1930&year_end=2022&corpus=en&smoothing=3&case_insensitive=false

-- 
Best,
Xuneng