Re: Patch to document base64 encoding

From: "Karl O(dot) Pinc" <kop(at)karlpinc(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
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-09 04:32:26
Message-ID: 20200108223226.4e39b1cf@slate.karlpinc.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 6 Jan 2020 01:35:00 -0600
"Karl O. Pinc" <kop(at)meme(dot)com> wrote:

> On Sun, 5 Jan 2020 12:48:59 +0100 (CET)
> Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:

> > 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.
>
> Ok. Done.

> If you're interested, another possibility would be the
> consistent use of "data bytea" everywhere.

> But then the word
> "string" does not really fit in a lot of the descriptions.
> So this choice would involve re-writing descriptions
...

> The trouble with using "data bytea" is that there might
> need to be adjustments to the word "string" elsewhere in
> the section, not just in the descriptions.
>
> Let me know if you'd prefer "data bytea" to "string bytea"
> and consequent frobbing of descriptions. That might be
> out-of-scope for this patch. (Which is already
> a poster-child for feature-creep.)

Another option would be to use "bytes bytea".
(The current patch uses "string bytea".)
This would probably also require some re-wording throughout.

Please let me know your preference. Thanks.

Regards,

Karl <kop(at)karlpinc(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Lepikhov 2020-01-09 04:47:26 Re: NOT IN subquery optimization
Previous Message Michael Paquier 2020-01-09 04:06:12 Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema