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 |
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 |