Re: BUG #5469: regexp_matches() has poor behaviour and more poor documentation

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5469: regexp_matches() has poor behaviour and more poor documentation
Date: 2010-05-29 21:00:55
Message-ID: 201005292100.o4TL0tf27606@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


I have updated the patch, attached, to clarify that this returns text
arrays, and that you can force it to always return one row using
COALESCE() and a '|' pattern (the later suggested by Daniele Varrazzo).

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Daniele Varrazzo wrote:
> > "If there is no match to the pattern, the function returns no rows" is
> > easily overlooked as "it returns null", or some other behaviour that
> > don't change the returned set. The point is, because the function is
> > listed in the string function, you would expect the function to
> > manipulate text, not the dataset. The function as it is is not safe to
> > be used in a construct
> >
> > SELECT foo, bar, regexp_matches(bar, pattern) FROM table;
> >
> > unless you really wanted:
> >
> > SELECT foo, bar, regexp_matches(bar, pattern) FROM table WHERE bar
> > ~ pattern;
> >
> > otherwise you have to take measures to be able to deal with records in
> > which the pattern is not matched, for example:
> >
> > SELECT foo, bar, regexp_matches(bar, pattern || '|') FROM table;
> >
> > the latter still doesn't work when bar is NULL: in this case the
> > record is dropped anyway, so I don't think it can be proposed as
> > general solution.
> >
> > The characteristics of returning a set of text[] is useful when the
> > user wants all the matches, not only the first one: the behaviour is
> > selected specifying the flag 'g' as third argument.
> >
> > >From this point of view, I hope it can be stated that in its current
> > form the regexp_matches() has not the most optimal interface. Please
> > accept my apology for the tone being too rude in my previous message.
>
> I found the description in the documentation quite confusing also. I
> have created the attached documention patch which is clearer about the
> behavior of regexp_matches().

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

Attachment Content-Type Size
/pgpatches/regexp text/x-diff 3.4 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2010-05-29 21:15:57 Re: BUG #5483: PQescapeStringConn behaviour ??
Previous Message Bruce Momjian 2010-05-29 19:06:30 Re: BUG #5477: CREATE DOMAIN NOT NULL constraints not always enforced for INSERT with subquery