Horton

Thread

Commits

  1. doc: Document pg_encoding_to_char() and pg_char_to_encoding().

  2. Add builtin functions:

  1. [PATCH] document

    Ian Lawrence Barwick <barwick@gmail.com> — 2021-07-14T05:43:52Z

    Hi

The description for "pg_database" [1] mentions the function
"pg_encoding_to_char()", but this is not described anywhere in the docs. Given
that that it (and the corresponding "pg_char_to_encoding()") have been around
since 7.0 [2], it's probably not a burning issue, but it seems not entirely
unreasonable to add short descriptions for both (and link from "pg_conversion"
while we're at it); see attached patch. "System Catalog Information Functions"
seems the most logical place to put these.

[1] https://www.postgresql.org/docs/current/catalog-pg-database.html
[2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5eb1d0deb15f2b7cd0051bef12f3e091516c723b

Will add to the next commitfest.

Regards

Ian Barwick

-- 
EnterpriseDB: https://www.enterprisedb.com

  2. Re: [PATCH] document

    Laurenz Albe <laurenz.albe@cybertec.at> — 2021-07-14T05:45:52Z

    On Wed, 2021-07-14 at 14:43 +0900, Ian Lawrence Barwick wrote:
> Hi
> 
> The description for "pg_database" [1] mentions the function
> "pg_encoding_to_char()", but this is not described anywhere in the docs. Given
> that that it (and the corresponding "pg_char_to_encoding()") have been around
> since 7.0 [2], it's probably not a burning issue, but it seems not entirely
> unreasonable to add short descriptions for both (and link from "pg_conversion"
> while we're at it); see attached patch. "System Catalog Information Functions"
> seems the most logical place to put these.
> 
> [1] https://www.postgresql.org/docs/current/catalog-pg-database.html
> [2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5eb1d0deb15f2b7cd0051bef12f3e091516c723b
> 
> Will add to the next commitfest.

+1

Yours,
Laurenz Albe

  3. Re: [PATCH] document pg_encoding_to_char() and pg_char_to_encoding()

    Ian Lawrence Barwick <barwick@gmail.com> — 2021-07-14T07:13:57Z

    2021年7月14日(水) 14:43 Ian Lawrence Barwick <barwick@gmail.com>:
>
> Hi
>
> The description for "pg_database" [1] mentions the function
> "pg_encoding_to_char()", but this is not described anywhere in the docs. Given
> that that it (and the corresponding "pg_char_to_encoding()") have been around
> since 7.0 [2], it's probably not a burning issue, but it seems not entirely
> unreasonable to add short descriptions for both (and link from "pg_conversion"
> while we're at it); see attached patch. "System Catalog Information Functions"
> seems the most logical place to put these.
>
> [1] https://www.postgresql.org/docs/current/catalog-pg-database.html
> [2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5eb1d0deb15f2b7cd0051bef12f3e091516c723b
>
> Will add to the next commitfest.

Added; apologies, the subject line of the original mail was
unintentionally truncated.

Regards

Ian Barwick

-- 
EnterpriseDB: https://www.enterprisedb.com

  4. Re: [PATCH] document

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2021-08-25T13:21:36Z

    
On 2021/07/14 14:45, Laurenz Albe wrote:
> On Wed, 2021-07-14 at 14:43 +0900, Ian Lawrence Barwick wrote:
>> Hi
>>
>> The description for "pg_database" [1] mentions the function
>> "pg_encoding_to_char()", but this is not described anywhere in the docs. Given
>> that that it (and the corresponding "pg_char_to_encoding()") have been around
>> since 7.0 [2], it's probably not a burning issue, but it seems not entirely
>> unreasonable to add short descriptions for both (and link from "pg_conversion"
>> while we're at it); see attached patch. "System Catalog Information Functions"
>> seems the most logical place to put these.
>>
>> [1] https://www.postgresql.org/docs/current/catalog-pg-database.html
>> [2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5eb1d0deb15f2b7cd0051bef12f3e091516c723b
>>
>> Will add to the next commitfest.
> 
> +1

+1

When I applied the patch to the master, I found that the table entries for
those function were added into the table for aclitem functions in the docs.
I think this is not valid position and needs to be moved to the proper one
(maybe the table for system catalog information functions?).

+        <returnvalue>int</returnvalue>
+        <function>pg_encoding_to_char</function> ( <parameter>encoding</parameter> <type>int</type> )

It's better to s/int/integer because the entries for other functions
in func.sgml use "integer".

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

  5. Re: [PATCH] document

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-08-25T13:50:13Z

    Fujii Masao <masao.fujii@oss.nttdata.com> writes:
> When I applied the patch to the master, I found that the table entries for
> those function were added into the table for aclitem functions in the docs.
> I think this is not valid position and needs to be moved to the proper one
> (maybe the table for system catalog information functions?).

You have to be very careful these days when applying stale patches to
func.sgml --- there's enough duplicate boilerplate that "patch' can easily
be fooled into dumping an addition into the wrong place.  I doubt that
the submitter meant the doc addition to go there.

			regards, tom lane

  6. Re: [PATCH] document

    Justin Pryzby <pryzby@telsasoft.com> — 2021-08-25T16:39:59Z

    On Wed, Aug 25, 2021 at 09:50:13AM -0400, Tom Lane wrote:
> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
> > When I applied the patch to the master, I found that the table entries for
> > those function were added into the table for aclitem functions in the docs.
> > I think this is not valid position and needs to be moved to the proper one
> > (maybe the table for system catalog information functions?).
> 
> You have to be very careful these days when applying stale patches to
> func.sgml --- there's enough duplicate boilerplate that "patch' can easily
> be fooled into dumping an addition into the wrong place.  I doubt that
> the submitter meant the doc addition to go there.

I suppose one solution to this is to use git format-patch -U11 or similar, at
least for doc/

Or write the "duplicate boilerplate" across fewer lines.

And another is to add <!-- function() --> comments before and/or after each.

-- 
Justin

  7. Re: [PATCH] document

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2021-10-04T06:18:04Z

    
On 2021/08/26 1:39, Justin Pryzby wrote:
> On Wed, Aug 25, 2021 at 09:50:13AM -0400, Tom Lane wrote:
>> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
>>> When I applied the patch to the master, I found that the table entries for
>>> those function were added into the table for aclitem functions in the docs.
>>> I think this is not valid position and needs to be moved to the proper one
>>> (maybe the table for system catalog information functions?).
>>
>> You have to be very careful these days when applying stale patches to
>> func.sgml --- there's enough duplicate boilerplate that "patch' can easily
>> be fooled into dumping an addition into the wrong place.  I doubt that
>> the submitter meant the doc addition to go there.
> 
> I suppose one solution to this is to use git format-patch -U11 or similar, at
> least for doc/

Yes. I moved the desriptions of the function into the table for
system catalog information functions, and made the patch by using
git diff -U6. Patch attached. Barring any objection, I'm thinking
to commit it.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

  8. Re: [PATCH] document

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2021-10-05T03:55:13Z

    
On 2021/10/04 15:18, Fujii Masao wrote:
> 
> 
> On 2021/08/26 1:39, Justin Pryzby wrote:
>> On Wed, Aug 25, 2021 at 09:50:13AM -0400, Tom Lane wrote:
>>> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
>>>> When I applied the patch to the master, I found that the table entries for
>>>> those function were added into the table for aclitem functions in the docs.
>>>> I think this is not valid position and needs to be moved to the proper one
>>>> (maybe the table for system catalog information functions?).
>>>
>>> You have to be very careful these days when applying stale patches to
>>> func.sgml --- there's enough duplicate boilerplate that "patch' can easily
>>> be fooled into dumping an addition into the wrong place.  I doubt that
>>> the submitter meant the doc addition to go there.
>>
>> I suppose one solution to this is to use git format-patch -U11 or similar, at
>> least for doc/
> 
> Yes. I moved the desriptions of the function into the table for
> system catalog information functions, and made the patch by using
> git diff -U6. Patch attached. Barring any objection, I'm thinking
> to commit it.

Pushed. Thanks!

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION