| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> |
| Cc: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Improve error message for duplicate labels in enum types |
| Date: | 2025-09-02 18:00:52 |
| Message-ID: | 662497.1756836052@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-09-02 18:10:08 | Re: Disabling memory overcommit deemed dangerous |
| Previous Message | Ranier Vilela | 2025-09-02 17:46:58 | Re: Avoid use of uninitialized variable (src/pl/plperl/plperl.c) |