Re: Improve error message for duplicate labels in enum types
От | Yugo Nagata |
---|---|
Тема | Re: Improve error message for duplicate labels in enum types |
Дата | |
Msg-id | 20250903200538.5588b917c9a813a0f7dd6d7e@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: Improve error message for duplicate labels in enum types (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, 2 Sep 2025 14:00:52 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Jim Jones <jim.jones@uni-muenster.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@sraoss.co.jp>
В списке pgsql-hackers по дате отправления: