Re: Should we allow ALTER OPERATOR CLASS to ADD/DROP operators and procedures?
От | Tomas Vondra |
---|---|
Тема | Re: Should we allow ALTER OPERATOR CLASS to ADD/DROP operators and procedures? |
Дата | |
Msg-id | 2792c089-dae2-4ca1-9225-bdf362c5b906@vondra.me обсуждение исходный текст |
Ответ на | Should we allow ALTER OPERATOR CLASS to ADD/DROP operators and procedures? (Tomas Vondra <tomas@vondra.me>) |
Ответы |
Re: Should we allow ALTER OPERATOR CLASS to ADD/DROP operators and procedures?
|
Список | pgsql-hackers |
On 2/7/25 01:15, Tom Lane wrote: > Tomas Vondra <tomas@vondra.me> writes: >> Which is why PostGIS devs chose a different path - updating the catalogs >> to modify the opclass definition [3], using this script [4]. > >> That's a bit ... terrifying. > > Indeed. Did it not occur to them to use ALTER OPERATOR FAMILY? > No, it did not. But that may be my fault - I've reported the bug, and I've been discussing possible fixes with them, and it didn't occur to me either :-( It seems quite non-intuitive to fix a bug in OPERATOR CLASS by doing ALTER OPERATOR FAMILY. > The end result of doing so is that the added opfamily members > wouldn't have been bound tightly to the opclass, but that does > not seem like a huge deal in context. They'd still have worked > fine AFAIK. > I haven't tried but I assume you're suggesting adding the MERGE proc to the opfamily would be enough for the opclass to pick it up? However, I'm not sure this would be a complete fix, because what would they do with the existing ADD_VALUE proc? Sure, they could just tweak the C code to "redirect" the call to the built-in one. But that requires the MERGE proc being defined, so it'd crash if someone installs the new version .so but doesn't do ALTER EXTENSION ... UPDATE. regards -- Tomas Vondra
В списке pgsql-hackers по дате отправления: