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
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 |