On Sat, 18 Jan 2020 18:05:49 -0500
Tom Lane wrote:
> And there were some errors; notably, the patch added descriptions
> for shaNNN(text), which are functions we do not have AFAICS.
Apologies for that, my mistake.
Thank you to Fabien and everybody who helped.
Regards,
Karl
Free Software:
I've pushed this patch with some further hacking.
Most notably, I shoved the conversion-names table over to charset.sgml,
as I'd mused about doing upthread. It no longer had any reason at all
to be in section 9.4. We could have moved it down to 9.5, but I felt
that it would still be wrongly
Alvaro Herrera writes:
> Tom, you're marked as committer for this one in the commitfest app; are
> you still intending to get it committed? If not, I can.
I've not been paying much attention to this thread, but I'll take
another look.
regards, tom lane
Tom, you're marked as committer for this one in the commitfest app; are
you still intending to get it committed? If not, I can.
Thanks,
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, 16 Jan 2020 15:44:44 -0300
Alvaro Herrera wrote:
> Because of how the new tables look in the PDF docs, I thought it might
> be a good time to research how to make each function-entry occupy two
> rows: one for prototype, return type and description, and the other
> for the example and
On Thu, 16 Jan 2020 14:41:33 +0100 (CET)
Fabien COELHO wrote:
> Some comments about v13:
>
> The note about get_byte reads:
>
>get_byte and set_byte number the first byte of a binary string as
> byte 0. get_bit and set_bit number bits from the right within each
> byte; for example bit 0 is
On Thu, 16 Jan 2020 14:41:33 +0100 (CET)
Fabien COELHO wrote:
> The "Binary String Functions and Operators" 9.5 section has only one
> subsection, "9.5.1", which is about at two thirds of the page. This
> structure looks weird. ISTM that a subsection is missing for the
> beginning of the page,
I just wanted to throw this in the archives; this doesn't need to affect
your patch.
Because of how the new tables look in the PDF docs, I thought it might
be a good time to research how to make each function-entry occupy two
rows: one for prototype, return type and description, and the other for
Hello Karl,
New patch attached: doc_base64_v13.patch
This required surprisingly little re-wording.
Added word "binary" into the descriptions of convert(),
substring(), convert_from(), and convert_to().
I also added data types to the call syntax of set_bit()
and set_byte().
And this patch
On Thu, 9 Jan 2020 08:27:28 +0100 (CET)
Fabien COELHO wrote:
> > Another option would be to use "bytes bytea".
>
> > (The current patch uses "string bytea".)
> > This would probably also require some re-wording throughout.
> I like it, but this is only my own limited opinion, and I'm not a
Hello Karl,
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.
I like it, but this is only my own limited opinion, and I'm not a native
English
On Mon, 6 Jan 2020 01:35:00 -0600
"Karl O. Pinc" wrote:
> On Sun, 5 Jan 2020 12:48:59 +0100 (CET)
> Fabien COELHO 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
Hello Fabien,
On Sun, 5 Jan 2020 12:48:59 +0100 (CET)
Fabien COELHO wrote:
> 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.
I assume by this you mean you are happy with the organization
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.
+ bytea ||
+bytea
bytea
Hi,
Attached is doc_base64_v11.patch
This addresses Tom's concerns. Functions
that operate on both strings and bytea
(e.g. length(text) and length(bytea))
are documented separately, one with
string functions and one with binary
string functions.
In this iteration I have also:
Added a
On 2019-Aug-02, Karl O. Pinc wrote:
> On Fri, 02 Aug 2019 10:44:43 -0400
> Tom Lane wrote:
>
> > I don't really have a problem with
> > repeating the entries for other functions that exist in both
> > text and bytea variants, either.
>
> Ok. Thanks. I'll repeat entries then.
Hello Karl,
On Fri, 02 Aug 2019 10:44:43 -0400
Tom Lane wrote:
> I don't really have a problem with
> repeating the entries for other functions that exist in both
> text and bytea variants, either.
Ok. Thanks. I'll repeat entries then.
Regards,
Karl
Free Software: "You don't pay back, you pay
On 8/2/19 10:32 AM, Karl O. Pinc wrote:
> But I'm not happy with putting any function that works with
> bytea into the binary string section. This would mean moving,
> say, length() out of the regular string section.
I'm not sure why. The bytea section already has an entry for its
length()
"Karl O. Pinc" writes:
> But I'm not happy with putting any function that works with
> bytea into the binary string section. This would mean moving,
> say, length() out of the regular string section. There's a
> lot of functions that work on both string and bytea inputs
> and most (not all, see
On Tue, 30 Jul 2019 23:44:49 +0200 (CEST)
Fabien COELHO wrote:
> Personnaly, I'd be ok with having a separate "conversion function"
> table, and also with Tom suggestion to have string functions with
> "only simple string" functions, and if any binary appears it is moved
> into the binary
On Wed, Jul 31, 2019 at 6:27 AM Karl O. Pinc wrote:
> On Tue, 30 Jul 2019 11:40:03 -0400
> Tom Lane wrote:
> [review]
> Thanks for the help. I will wait for a response to this
> before submitting another patch, just in case someone sees any
> ideas here to be followed up on.
Based on the
My 0.02 €
It seems entirely crazy that encode() and decode() are no longer in the
same section, likewise that convert_from() and convert_to() aren't
documented together anymore.
Awkward, yes. But findable if you know what the categories are.
I suppose there could be 3 different
On Tue, 30 Jul 2019 11:40:03 -0400
Tom Lane wrote:
> "Karl O. Pinc" writes:
> > On Mon, 15 Jul 2019 23:00:55 +0200 (CEST)
> > Fabien COELHO wrote:
> >> The patch clarifies the documentation about encode/decode and
> >> other text/binary string conversion functions.
>
> > Other notable
"Karl O. Pinc" writes:
> On Mon, 15 Jul 2019 23:00:55 +0200 (CEST)
> Fabien COELHO wrote:
>> The patch clarifies the documentation about encode/decode and other
>> text/binary string conversion functions.
> Other notable changes:
> Corrects categorization of functions as string or binary.
>
On Mon, 15 Jul 2019 23:00:55 +0200 (CEST)
Fabien COELHO wrote:
> The patch clarifies the documentation about encode/decode and other
> text/binary string conversion functions.
Other notable changes:
Corrects categorization of functions as string or binary.
Reorders functions
Hello Karl,
Attached is doc_base64_v10.patch
Patch applies cleanly. Doc gen ok.
The patch clarifies the documentation about encode/decode and other
text/binary string conversion functions.
No further comments beyond the title thing (Function x) already discussed,
which is not a
Hello Karl,
It really works in research papers: "Theorem X can be proven by
applying Proposition Y. See Figure 2 for details. Algorithm Z
describes whatever, which is listed in Table W..."
I've not thought about it before but I suppose the difference is between
declarative and descriptive,
Hi Fabien,
Attached is doc_base64_v10.patch
On Fri, 12 Jul 2019 15:58:21 +0200 (CEST)
Fabien COELHO wrote:
> >> I suggested "Function <>decode ...", which is the kind of thing
> >> we do in academic writing to improve precision, because I thought
> >> it could be better:-)
> >
> > "Function
Hello Karl,
doc_base64_part1_v9.patch
Only moves, eliminates duplicates, and adjusts indentation.
doc_base64_part2_v9.patch
Cleanup wording after moving functions between sections.
doc_base64_part3_v9.patch
Documents base64, hex, and escape encode() and decode()
formats.
I
On Thu, 9 May 2019 06:50:12 +0200 (CEST)
Fabien COELHO wrote:
> You might consider reviewing other people patches, that is expected
> to make the overall process work. There are several documentation or
> comment patches in the queue.
Understood.
I thought I had built up some reviewing
Er, ping. Nobody has reviewed the latest patchs.
Next CF is in July, two months away.
You might consider reviewing other people patches, that is expected to
make the overall process work. There are several documentation or
comment patches in the queue.
--
Fabien.
Er, ping. Nobody has reviewed the latest patchs.
They still apply to master...
I am re-attaching the patches. See descriptions
below.
On Mon, 11 Mar 2019 15:32:14 -0500
"Karl O. Pinc" wrote:
> On Sun, 10 Mar 2019 08:15:35 +0100 (CET)
> Fabien COELHO What's causing problems here is that the
Hi Fabien,
On Sun, 10 Mar 2019 08:15:35 +0100 (CET)
Fabien COELHO I registered as a reviewer in the CF app.
Thanks.
What's causing problems here is that the encode and decode
functions are listed in both the string functions section
and the binary functions section. A related but not-relevant
Hello Karl,
I registered as a reviewer in the CF app.
"The string and the binary encode and decode functions..." sentence
looks strange to me, especially with the English article that I do
not really master, so maybe it is ok. I'd have written something more
straightforward, eg: "Functions
Hi Fabien (and Michael),
On Wed, 6 Mar 2019 16:37:05 -0600
"Karl O. Pinc" wrote:
> I'm confident that the behavior I documented is how PG behaves
> but you should know what I did in case you want further
> validation.
>
> Attached: doc_base64_v8.patch
FYI. To avoid a stall in the patch
On Wed, 6 Mar 2019 19:30:16 +0100 (CET)
Fabien COELHO wrote:
> "... section 6.8" -> "... Section 6.8" (capital S).
Fixed.
> "The string and the binary encode and decode functions..." sentence
> looks strange to me, especially with the English article that I do
> not really master, so maybe it
Attached: doc_base64_v7.patch
Patch applies cleanly, doc compiles, navigation tested and ok.
"... section 6.8" -> "... Section 6.8" (capital S).
"The string and the binary encode and decode functions..." sentence looks
strange to me, especially with the English article that I do not
On Wed, 6 Mar 2019 07:09:48 -0600
"Karl O. Pinc" wrote:
> On Tue, 5 Mar 2019 23:23:20 -0600
> "Karl O. Pinc" wrote:
>
> > Added documentation for hex and escape encodings,
> > including output formats and what are acceptable
> > inputs.
Attached: doc_base64_v7.patch
Improved escape
On Tue, 5 Mar 2019 23:23:20 -0600
"Karl O. Pinc" wrote:
> Added documentation for hex and escape encodings,
> including output formats and what are acceptable
> inputs.
Attached: doc_base64_v6.patch
Added index entries for encode and decode functions
above the encoding documentation. As index
On Wed, 6 Mar 2019 11:27:38 +0900
Michael Paquier wrote:
> On Tue, Mar 05, 2019 at 07:55:22PM -0600, Karl O. Pinc wrote:
> > Attached: doc_base64_v4.patch
>
> Details about the "escape" mode are already available within the
> description of function "encode". Wouldn't we want to consolidate
On Tue, Mar 05, 2019 at 07:55:22PM -0600, Karl O. Pinc wrote:
> Attached: doc_base64_v4.patch
Details about the "escape" mode are already available within the
description of function "encode". Wouldn't we want to consolidate a
description for all the modes at the same place, including some words
Hi Fabien,
On Tue, 5 Mar 2019 23:02:26 +0100 (CET)
Fabien COELHO wrote:
> > Attached: doc_base64_v3.patch
>
> I'm ok with referencing the historical MIME RFC.
For the record, RFC 2045 is updated but not
yet obsolete. The updates don't invalidate
section 6.8.
> "RFC2045 section 6.8" ->
Hello Karl,
Attached: doc_base64_v3.patch
I'm ok with referencing the historical MIME RFC.
"RFC2045 section 6.8" -> "RFC 2045 Section 6.8"
you can link to the RFC directly with:
https://tools.ietf.org/html/rfc2045#section-6.8;>RFC 2045
Section 6.8
--
Fabien.
On Tue, 5 Mar 2019 07:26:17 -0600
"Karl O. Pinc" wrote:
> (I am not entirely pleased with the double dash
> but can't come up with anything better. And
> can't make an emdash entity work either.)
Attached: doc_base64_v3.patch
There is an mdash entity. This patch uses that.
Regards,
Karl
Hi Fabien,
On Tue, 5 Mar 2019 07:09:01 +0100 (CET)
Fabien COELHO wrote:
> > Doc patch, against master. Documents encode() and decode() base64
> > format.
>
> It is already documented. Enhance documentation, though.
Right. I was thinking that there are various implementations
of the
Hello Karl,
Doc patch, against master. Documents encode() and decode() base64
format.
It is already documented. Enhance documentation, though.
Builds for me.
For me as well. Looks ok.
Attached: doc_base64_v1.patch
References RFC2045 section 6.8 to define base64.
Did you consider
46 matches
Mail list logo
