Re: Patch to document base64 encoding

Поиск
Список
Период
Сортировка
От Karl O. Pinc
Тема Re: Patch to document base64 encoding
Дата
Msg-id 20200108223226.4e39b1cf@slate.karlpinc.com
обсуждение исходный текст
Ответ на Re: Patch to document base64 encoding  ("Karl O. Pinc" <kop@meme.com>)
Ответы Re: Patch to document base64 encoding
Список pgsql-hackers
On Mon, 6 Jan 2020 01:35:00 -0600
"Karl O. Pinc" <kop@meme.com> wrote:

> On Sun, 5 Jan 2020 12:48:59 +0100 (CET)
> Fabien COELHO <coelho@cri.ensmp.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@karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Assert failure due to "drop schema pg_temp_3 cascade" fortemporary tables and \d+ is not showing any info after drooping temp tableschema
Следующее
От: Andrey Lepikhov
Дата:
Сообщение: Re: NOT IN subquery optimization