Re: Patch to document base64 encoding

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: "Karl O(dot) Pinc" <kop(at)meme(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: Patch to document base64 encoding
Date: 2020-01-05 11:48:59
Message-ID: alpine.DEB.2.21.2001051231500.1648@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Karl,

> Attached is doc_base64_v11.patch

Patch applies cleanly and compiles.

I'm in favor of moving and reorganizing these function descriptions, as
they are somehow scattered with a unclear logic when you are looking for
them.

+ <entry><literal><parameter>bytea</parameter> <literal>||</literal>
+ <parameter>bytea</parameter></literal></entry>
<entry> <type>bytea</type> </entry>
<entry>
String concatenation

Bytea concatenation?

I'm not keen on calling the parameter the name of its type. I'd suggest to
keep "string" as a name everywhere, which is not a type name in Pg.

The functions descriptions are not homogeneous. Some have parameter name &
type "btrim(string bytea, bytes bytea)" and others only type or parameter
with tagged as a parameter "get_bit(bytea, offset)" (first param),
"sha224(bytea)".

I'd suggest to be consistent, eg use "string bytea" everywhere
appropriate.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2020-01-05 11:59:10 Re: parallel vacuum options/syntax
Previous Message Amit Kapila 2020-01-05 10:26:35 Re: parallel vacuum options/syntax