From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL-documentation <pgsql-docs(at)postgresql(dot)org> |
Subject: | Re: regexp_replace 'g' flag |
Date: | 2013-09-06 01:59:13 |
Message-ID: | 5459.1378432753@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Thu, Sep 5, 2013 at 08:37:44PM -0400, Bruce Momjian wrote:
>> Why doesn't the 'g' flag appear in this table?
>> http://www.postgresql.org/docs/9.2/static/functions-matching.html#POSIX-EMBEDDED-OPTIONS-TABLE
> Is it because the table has generic pattern modififers and 'g' only is
> relevant for regexp_replace? I assume so.
The table is specifically about ARE options, and 'g' is *not* one of
those. Adding 'g' to the table would be wrong.
It does seem to me to be a bit confusing that the text description of
substring() mentions 'i' and 'g' explicitly, when only 'i' is listed in
the table. You could make a case for phrasing along the line of
"substring() supports the 'g' flag that specifies ..., as well as all the
flags listed in Table 9-19". On the other hand, 'i' is the most useful of
the flags listed in the table by several country miles, and it doesn't
seem quite right to make people go off and consult the table to find out
about it.
Not sure whether there's any real improvement that can be made here,
but I suppose it'd be nice if the text descriptions of substring() and
regexp_replace() handled this matter in the same way ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Johnston | 2013-09-06 14:53:48 | Re: regexp_replace 'g' flag |
Previous Message | Bruce Momjian | 2013-09-06 00:51:02 | Re: regexp_replace 'g' flag |