Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
| От | David E. Wheeler |
|---|---|
| Тема | Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part |
| Дата | |
| Msg-id | 931F201B-FF38-486E-BDEE-DF9692A01E1D@justatheory.com обсуждение исходный текст |
| Ответ на | Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part (Florents Tselai <florents.tselai@gmail.com>) |
| Ответы |
Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
|
| Список | pgsql-hackers |
On Jan 31, 2026, at 11:23, Florents Tselai <florents.tselai@gmail.com> wrote: > I think your attachment was left behind. Attaching it myself (that's v17, right? ) checked out from your PR Bah! Yes, thank you. > With the refactoring you’ve done across the parser and executor, > I’m already tempted to slip in a few more string methods - but I think we should leave that for a future iteration. > Functionally, it’d just mean adding another branch in executeStringInternalMethod, > and I’d rather keep this patch focused. Agreed. > At this point, I’d say it’s ready for committer review. > > That said, I do expect someone to raise (again) the question of > how we want to handle potential future conflicts with the SQL/JSON standard. > That’s a broader design topic, and it’s going to come up every time we extend the JSONPath language. Yup, continual challenge, part of the deal IME. > And yes, I’m obviously biased here - I already have two other patches in the same spirit queued up, namely > https://commitfest.postgresql.org/patch/6429/ > https://commitfest.postgresql.org/patch/6436/ Ha! Message received, I’ll try to find some time to look at them. D
Вложения
В списке pgsql-hackers по дате отправления: