Re: Patch to document base64 encoding - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Patch to document base64 encoding
Date
Msg-id alpine.DEB.2.21.2001051231500.1648@pseudo
Whole thread Raw
In response to Re: Patch to document base64 encoding  ("Karl O. Pinc" <kop@meme.com>)
Responses Re: Patch to document base64 encoding  ("Karl O. Pinc" <kop@meme.com>)
List 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.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: parallel vacuum options/syntax
Next
From: Tomas Vondra
Date:
Subject: Re: parallel vacuum options/syntax