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.
