Re: patch adding new regexp functions
От | Tom Lane |
---|---|
Тема | Re: patch adding new regexp functions |
Дата | |
Msg-id | 19417.1171729151@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: patch adding new regexp functions (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: patch adding new regexp functions
Re: patch adding new regexp functions |
Список | pgsql-patches |
Peter Eisentraut <peter_e@gmx.net> writes: > David Fetter wrote: >> What is it about having the whole match, pre-match and post-match >> available that you're objecting to? Are you saying there aren't >> common uses for any or all of these? Regular expression users use >> them all over the place, > You keep saying that, and I keep saying please show a use case. Maybe I'm missing something, but ISTM that given the ability to return multiple match substrings there is no need for such features. Given an arbitrary regex 'xyz', write '^(.*)(xyz)(.*)$' and you'll get back the pre-match, whole match, and post-match in addition to any parenthesized substrings that 'xyz' contains. If you only need some of them, you can leave out the corresponding parts of this pattern. So I'd vote against complicating the API in order to make special provision for these results. I claim that all we need is a function taking (string text, pattern text, flags text) and returning either array of text or setof text containing the matched substrings in whatever order is standard (order by left-parenthesis position, I think). In the degenerate case where there are no parenthesized subpatterns, just return the whole match as a single element. As for the argument about array vs setof, I could see doing both to end the argument of which one is really superior for any particular problem. regards, tom lane
В списке pgsql-patches по дате отправления: