Re: [PATCHES] small doc patch for regexp_replace

Is there any reason, why regexp_replace is not included in the tables of the
string functions?

http://developer.postgresql.org/docs/postgres/functions-string.html

The appended patch adds regexp_replace() and links to the pattern matching
section for substring / regexp_replace.

I noticed that in the table the declaration of the arguments is
inconsistent, for example:

lower(string)
ascii(text)
length(string text)

also in the sgml, there is sometimes "text" and sometimes
"<type>text</type>".

I'd fix that if someone told me what the preferred (if any) form is...

Joachim

Joachim Wieland wrote:
> Is there any reason, why regexp_replace is not included in the tables of the
> string functions?
>
> http://developer.postgresql.org/docs/postgres/functions-string.html
>
> The appended patch adds regexp_replace() and links to the pattern matching
> section for substring / regexp_replace.
>
> I noticed that in the table the declaration of the arguments is
> inconsistent, for example:
>
> lower(string)
> ascii(text)
> length(string text)
>
> also in the sgml, there is sometimes "text" and sometimes
> "<type>text</type>".
>
> I'd fix that if someone told me what the preferred (if any) form is...

Seems there is some inconsistency there. There are two types of
function listings, one with just the types, and another with param_name
and then type. We use "string" instead of "text" because varchar() and
char() can also be used.

Anyway, applied patch attached that tries to clean it up. Let me know
if you find others.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Seems there is some inconsistency there. There are two types of
> function listings, one with just the types, and another with param_name
> and then type. We use "string" instead of "text" because varchar() and
> char() can also be used.

Where did that come from? The actual functions generally take "text",
relying on implicit conversions to handle the other types. Since we do
not have any type named "string", I think the locution <type>string</>
is a contradiction in terms.

IMHO these should all go back to <type>text</>.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Seems there is some inconsistency there. There are two types of
> > function listings, one with just the types, and another with param_name
> > and then type. We use "string" instead of "text" because varchar() and
> > char() can also be used.
>
> Where did that come from? The actual functions generally take "text",
> relying on implicit conversions to handle the other types. Since we do
> not have any type named "string", I think the locution <type>string</>
> is a contradiction in terms.
>
> IMHO these should all go back to <type>text</>.

Well, we actually have <parameter>string</> and I got a few wrong. I
have committed the changes. If we want to use <type>text</> instead
of <parameter>string</>, I can make that change too. There are quite a
few of them, like md5(). Yes?

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Seems there is some inconsistency there. There are two types of
> > function listings, one with just the types, and another with param_name
> > and then type. We use "string" instead of "text" because varchar() and
> > char() can also be used.

There are many mentions of <parameter>string</> used a function
arguments in func.sgml. Should those be changed to <type>text</>?

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> There are many mentions of <parameter>string</> used a function
> arguments in func.sgml. Should those be changed to <type>text</>?

<parameter>string</> is fine, especially if the function actually has a
separate variant for bpchar. I was just unhappy with <type>string</>,
which is a lie.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > There are many mentions of <parameter>string</> used a function
> > arguments in func.sgml. Should those be changed to <type>text</>?
>
> <parameter>string</> is fine, especially if the function actually has a
> separate variant for bpchar. I was just unhappy with <type>string</>,

FYI, in most cases, they don't have bpchar variants.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Patch applied. Thanks. Your documentation changes can be viewed in
five minutes using links on the developer's page,
http://www.postgresql.org/developer/testing.

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

Joachim Wieland wrote:
> Is there any reason, why regexp_replace is not included in the tables of the
> string functions?
>
> http://developer.postgresql.org/docs/postgres/functions-string.html
>
> The appended patch adds regexp_replace() and links to the pattern matching
> section for substring / regexp_replace.
>
> I noticed that in the table the declaration of the arguments is
> inconsistent, for example:
>
> lower(string)
> ascii(text)
> length(string text)
>
> also in the sgml, there is sometimes "text" and sometimes
> "<type>text</type>".
>
> I'd fix that if someone told me what the preferred (if any) form is...
>
>
> Joachim

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +