Re: Improve error message for duplicate labels in enum types

From: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improve error message for duplicate labels in enum types
Date: 2025-09-03 11:05:38
Message-ID: 20250903200538.5588b917c9a813a0f7dd6d7e@sraoss.co.jp
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2 Sep 2025 14:00:52 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> writes:
> > LGTM; I'll mark the CF entry as Ready for Committer.
>
> Pushed with some trivial cosmetic adjustments, including the
> perhaps-not-so-trivial fix of removing the comment you falsified.

Thank you for committing the patch and for fixing it.

> I was concerned about Rahila's upthread worry about the performance
> of this approach, but in some quick testing it seemed to add only
> barely-noticeable overhead even at 1000 enum labels. At 10000
> labels it's slightly annoying: my machine goes from ~80ms to ~250ms.
> But that seems well beyond what anybody would be likely to use,
> so I judge it not worth trying to be smarter.
>
> The obvious solution if we did wish to avoid the O(N^2) behavior would
> be to qsort the labels and then compare only adjacent ones. That'd
> require a temporary array though, and I'd bet it's actually slower
> than this way for normal-sized enums. Another possibility perhaps is
> to apply the check only when there are fewer than say 1000 labels,
> reasoning that anything bigger is probably machine-generated anyhow.

I also thought the O(N^2) behavior was acceptable, since it seemed unlikely
that users would try to create such a large number of enum labels.
If any complaints arise in the future, we can address them then.

Regards,
Yugo Nagata

--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chiranmoy.Bhattacharya@fujitsu.com 2025-09-03 11:11:24 Re: [PATCH] Hex-coding optimizations using SVE on ARM.
Previous Message Peter Eisentraut 2025-09-03 10:15:44 Re: Generate GUC tables from .dat file