Re: patch adding new regexp functions
От | Jeremy Drake |
---|---|
Тема | Re: patch adding new regexp functions |
Дата | |
Msg-id | Pine.BSO.4.64.0702161502280.18849@resin.csoft.net обсуждение исходный текст |
Ответ на | Re: patch adding new regexp functions (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: patch adding new regexp functions
|
Список | pgsql-patches |
On Fri, 16 Feb 2007, Peter Eisentraut wrote: > Am Freitag, 16. Februar 2007 08:02 schrieb Jeremy Drake: > > Does this version sufficiently address your concerns? > > I don't think anyone asked for the start position and length in the result of > regexp_split(). The result should be an array of text. That is what Perl et > al. do. The length is not returned, I simply call length() on the string result to make sure that no whitespace gets in. The start position was suggested in these two messages from Alvaro Herrera: http://archives.postgresql.org/pgsql-patches/2007-02/msg00276.php http://archives.postgresql.org/pgsql-patches/2007-02/msg00281.php This was meant to address your concern about the order not necessarily being preserved of the split results when being returned as SETOF. This gives the benefits of returning SETOF while still allowing the order to be preserved if desired (simply add ORDER BY startpos to guarantee the correct order). In case you haven't noticed, I am rather averse to making this return text[] because it is much easier in my experience to use the results when returned in SETOF rather than text[], and in all of the code that I have experience with where this would be useful I would end up using information_schema._pg_expandarray (a function that, AFAIK, is documented nowhere) to convert it into SETOF text. While, if you really really wanted a text[], you could use the (fully documented) ARRAY(select resultstr from regexp_split(...) order by startpos) construct. > As for the regexp_matches() function, it seems to me that it returns too much > information at once. What is the use case for getting all of prematch, > fullmatch, matches, and postmatch in one call? It was requested by David Fetter: http://archives.postgresql.org/pgsql-hackers/2007-02/msg00056.php It was not horribly difficult to provide, and it seemed reasonable to me. I have no need for them personally. -- Some people in this department wouldn't recognize subtlety if it hit them on the head.
В списке pgsql-patches по дате отправления: