On Thu, 28 Mar 2024 08:28:16 -0400
Robert Treat wrote:
> I spoke with Karl briefly on this and he is working on getting an
> updated patch together. The work now involves incorporating feedback
> and some rebasing, but hopefully we will see something in the next few
> days.
Well, Friday has
Hello,
Thank you all for your help. I won't be able to submit
new patches based on reviews for 2 weeks.
On Thu, 30 Nov 2023 16:02:28 +0530
Shubham Khanna wrote:
> -v7-0012-Explain-role-management.patch
>
> + The managment of most database objects is by way of granting some
> role
>
> Here
On Tue, 3 Oct 2023 14:51:31 -0700
"David G. Johnston" wrote:
> 0001 - I would just call the section:
> Capturing Command Results into Variables
I like your wording a lot. Let's use it!
> I would add commentary in there that it is only possible for
> variables to take on single value at any
On Mon, 2 Oct 2023 15:18:32 -0500
"Karl O. Pinc" wrote:
Version 7
Added:
v7-0016-Predicate-locks-are-held-per-cluster-not-per-data.patch
> > > On Mon, 25 Sep 2023 23:37:44 -0500
> > > "Karl O. Pinc" wrote:
> > >
> > > > > On M
On Sun, 1 Oct 2023 18:18:07 -0500
"Karl O. Pinc" wrote:
Version 6
Added:
v6-0015-Trigger-authors-need-not-worry-about-parallelism.patch
Can't say if this is an awesome idea or not. (Might have saved me time.)
Read the commit message for a justification.
> > On Mon, 25 S
23:37:44 -0500
> "Karl O. Pinc" wrote:
>
> > > On Mon, 25 Sep 2023 17:55:59 -0500
> > > "Karl O. Pinc" wrote:
> > >
> > > > On Mon, 25 Sep 2023 14:14:37 +0200
> > > > Daniel Gustafsson wrote:
> > >
Version 5
Changed word order in a sentence:
v5-0012-Explain-role-management.patch
Added a hyperlink:
v5-0013-Hyperlink-from-CREATE-FUNCTION-reference-page-to-.patch
Added 3 index entries:
v5-0014-Add-index-entries-for-parallel-safety.patch
> On Mon, 25 Sep 2023 23:37:44 -0500
> "K
Version 4.
Added: v4-0012-Explain-role-management.patch
On Mon, 25 Sep 2023 23:37:44 -0500
"Karl O. Pinc" wrote:
> > On Mon, 25 Sep 2023 17:55:59 -0500
> > "Karl O. Pinc" wrote:
> >
> > > On Mon, 25 Sep 2023 14:14:37 +0200
> > > Da
On Thu, 28 Sep 2023 12:54:33 +0900
Michael Paquier wrote:
> I was looking at this thread overall, the three v3 flavors of the doc
> changes and v4.
>
> -application_name value. Other characters
> will be
> -replaced with question marks (?).
> +application_name value.
> +
On Thu, 28 Sep 2023 09:49:03 +1000
Peter Smith wrote:
> On Wed, Sep 27, 2023 at 11:59 PM Karl O. Pinc
> wrote:
> >
> > On Wed, 27 Sep 2023 12:58:54 +
> > "Hayato Kuroda (Fujitsu)" wrote:
> >
> > > > Should the committer be interested, y
On Wed, 27 Sep 2023 12:58:54 +
"Hayato Kuroda (Fujitsu)" wrote:
> > Should the committer be interested, your patch applies cleanly
> > and the docs build as expected.
>
> Yeah, but cfbot accepted previous version. Did you have anything in
> your mind?
No. I'm letting the committer know
Sep 26, 2023 1:10:55 PM Tom Lane :
> "Karl O. Pinc" writes:
>> For the last hunk you'd change around "anything". Write:
>> "... it will be truncated to less than NAMEDATALEN characters and
>> the bytes of the string which are not printable ASCII
On Tue, 26 Sep 2023 13:40:26 +
"Hayato Kuroda (Fujitsu)" wrote:
> Your effort is quite helpful for me.
You're welcome.
> Before replying your comments, I thought I should show the difference
> between versions. Regarding old versions (here PG15 was used),
> non-ASCIIs (like Japanese) are
Hello Hayato and Jian,
On Tue, 4 Jul 2023 01:30:56 +
"Hayato Kuroda (Fujitsu)" wrote:
> Dear Jian,
> > looks fine. Do you need to add to commitfest?
>
> Thank you for your confirmation. ! I registered to following:
>
> https://commitfest.postgresql.org/44/4437/
The way the Postgres
Forgot to attach. Sorry.
On Mon, 25 Sep 2023 23:30:38 -0500
"Karl O. Pinc" wrote:
> Version 3.
>
> Re-do title, which is all of patch v3-003.
>
> On Mon, 25 Sep 2023 17:55:59 -0500
> "Karl O. Pinc" wrote:
>
> > On Mon, 25 Sep 2
Version 3.
Re-do title, which is all of patch v3-003.
On Mon, 25 Sep 2023 17:55:59 -0500
"Karl O. Pinc" wrote:
> On Mon, 25 Sep 2023 14:14:37 +0200
> Daniel Gustafsson wrote:
> > Once done you can do "git format-patch origin/master -v 1" which
> > wil
On Mon, 25 Sep 2023 14:14:37 +0200
Daniel Gustafsson wrote:
> > On 25 Sep 2023, at 14:00, Karl O. Pinc wrote:
>
> > Is there a preferred data format or should I send
> > each patch in a separate attachment with description?
> Once done you can do "git fo
On Mon, 25 Sep 2023 09:26:38 +0200
Daniel Gustafsson wrote:
> > On 25 Sep 2023, at 00:57, Karl O. Pinc wrote:
>
> > I have made various, mostly unrelated to each other,
> > small improvements to the documentation.
> While I agree it's subjective, I don't th
On Wed, 20 Sep 2023 13:39:02 +0900
Michael Paquier wrote:
> On Wed, Sep 20, 2023 at 09:43:15AM +0900, Shinya Kato wrote:
> > You're right. It looks good to me.
>
> Right, it feels like there has been a lot of copy-paste in this area
> of the docs. Applied down to 16.
I signed up to review,
Hi,
I have made various, mostly unrelated to each other,
small improvements to the documentation. These
are usually in the areas of plpgsql, schemas, and permissions.
Most change 1 lines, but some supply short overviews.
"Short" is subjective, so if these need to be
broken into different
On Thu, 13 Apr 2023 10:53:31 -0500
"Karl O. Pinc" wrote:
> On Thu, 13 Apr 2023 16:01:35 +0200
> Brar Piening wrote:
>
> > On 13.04.2023 at 10:31, Peter Eisentraut wrote:
> > > Side project: I noticed that these new hover links don't appear in
>
On Thu, 13 Apr 2023 16:01:35 +0200
Brar Piening wrote:
> On 13.04.2023 at 10:31, Peter Eisentraut wrote:
> > The first patch has been committed.
>
> Yay - thank you!
>
> > The second patch should be sent to pgsql-www for integrating into
> > the web site.
> Done via [1]. Thanks for the
On Thu, 13 Apr 2023 15:58:03 +0100
Dagfinn Ilmari Mannsåker wrote:
> Peter Eisentraut writes:
> > The first patch has been committed.
> Another side note: I notice the links don't appear on
> elements (e.g.
> https://www.postgresql.org/docs/devel/sql-select.html#SQL-WITH), only
> .
This we
On Thu, 6 Apr 2023 16:19:30 +0200
Brar Piening wrote:
> Reviewer is Karl O. Pink
"Karl O. Pinc" actually, with a "c".
Regards,
Karl
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
On Tue, 4 Apr 2023 21:52:31 +0200
Brar Piening wrote:
> On 04.04.2023 at 16:54, Peter Eisentraut wrote:
> > The XSLT implementation looks sound to me. It would be a touch
> > better if it had some comments about which parts of the templates
> > were copied from upstream stylesheets and which
On Wed, 29 Mar 2023 21:32:05 -0700
Noah Misch wrote:
> On Sun, Jan 22, 2023 at 02:42:46PM -0600, Karl O. Pinc wrote:
> > v10-0001-List-trusted-and-obsolete-extensions.patch
>
> > +
> > + These modules and
Hi Brar,
An observation: The # that shows up when hovering
over section-level headings is styled as the
section-level heading is. But the # that shows
up when hovering over varlistentrys has the default
text style.
This works for me. It's nice to have the "section #"s
look like the section
This is for the committer, as an FYI.
I cut out the portion
of the docbook XSLT and diffed it with the code for the
same template in the patch. The diff looks like:
-- /tmp/sections.xsl2023-03-22 13:00:33.432968357 -0500
+++ /tmp/make_html_ids_discoverable_v3.patch2023-03-22
Hi Brar,
It occurs to me that I had not actually tested the
way the anchor is put only after the last term in a
varlistentry. (The code looked obviously right
and should work if any varlistentry terms have anchors,
which they do, but)
Have you tested this? If not, catalog.sgml, the
On Thu, 23 Mar 2023 10:35:55 +0100
Alvaro Herrera wrote:
> As with the patch, we'll need to patch the CSS used in
> the website for the docs too, as that's the most important place
> where docs are visited. See this commit for an example:
>
On Thu, 23 Mar 2023 08:24:48 +0100
Brar Piening wrote:
> On 23.03.2023 at 04:09, Karl O. Pinc wrote:
> > Sorry for the extra work I've put you through.
>
> No problem. As always I've learnt something which may help me in the
> future.
I don't know about you, but sadly, m
On Tue, 21 Mar 2023 23:16:25 +0100
Brar Piening wrote:
> On 17.01.2023 at 23:43, Karl O. Pinc wrote:
> > It's good you asked. After poking about the XSLT 1.0 spec to
> > refresh my memory I abandoned the "mode" approach entirely. The
> > real "right
Hi Alvaro,
On Thu, 9 Mar 2023 10:22:49 +0100
Alvaro Herrera wrote:
> On 2023-Jan-22, Karl O. Pinc wrote:
>
> > Actually, this CSS, added to doc/src/sgml/stylesheet.css,
> > makes the column spacing look pretty good:
> Okay, this looks good to me too. However, for it
On Tue, 14 Feb 2023 12:13:18 -0800
Andres Freund wrote:
> A small note: As-is this fails on CI, because we don't allow network
> access during the docs build anymore (since it always fails these
> days):
>
> https://cirrus-ci.com/task/5474029402849280?logs=docs_build#L297
>
> [17:02:03.114]
On Wed, 25 Jan 2023 18:03:25 -0600
"Karl O. Pinc" Buried in
> https://www.postgresql.org/message-id/20230107165942.748ccf4e%40slate.karlpinc.com
> is the one change I see that should be made.
>
> > In doc/src/sgml/ref/allfiles.sgml at line 222 there is an ENTITY
>
Hello,
Somehow I missed the email changing the status of this back
to "needs review".
Buried in
https://www.postgresql.org/message-id/20230107165942.748ccf4e%40slate.karlpinc.com
is the one change I see that should be made.
> In doc/src/sgml/ref/allfiles.sgml at line 222 there is an ENTITY
>
On Sun, 22 Jan 2023 14:42:46 -0600
"Karl O. Pinc" wrote:
> Attached are 2 patches:
>
> v10-0001-List-trusted-and-obsolete-extensions.patch
>
> List trusted extenions in 4 columns, with the CSS altered
> to put spacing between vertical columns.
In theory,
On Sun, 22 Jan 2023 08:09:03 -0600
"Karl O. Pinc" wrote:
> On Sat, 21 Jan 2023 08:11:43 -0600
> "Karl O. Pinc" wrote:
>
> > Attached are 2 v9 patch versions. I don't think I like them.
> > I think the v8 versions are better. But I thought
On Sat, 21 Jan 2023 08:11:43 -0600
"Karl O. Pinc" wrote:
> Attached are 2 v9 patch versions. I don't think I like them.
> I think the v8 versions are better. But I thought it
> wouldn't hurt to show them to you.
>
> On Fri, 20 Jan 2023 14:22:25 -0600
> "Karl
Attached are 2 v9 patch versions. I don't think I like them.
I think the v8 versions are better. But I thought it
wouldn't hurt to show them to you.
On Fri, 20 Jan 2023 14:22:25 -0600
"Karl O. Pinc" wrote:
> Attached are 2 alternatives:
> (They touch separate files
On Fri, 20 Jan 2023 14:22:25 -0600
"Karl O. Pinc" wrote:
> v8-0001-List-trusted-and-obsolete-extensions.patch
>
> Instead of putting [trusted] and [obsolete] in the titles
> of the modules, like v7 does, add a list of them into the text.
The list is inline.
On Fri, 20 Jan 2023 20:12:38 +0100
Alvaro Herrera wrote:
> Ah, I wanted to attach the two remaining patches and forgot.
Attached are 2 alternatives:
(They touch separate files so the ordering is meaningless.)
v8-0001-List-trusted-and-obsolete-extensions.patch
Instead of putting [trusted]
On Fri, 20 Jan 2023 20:12:03 +0100
Alvaro Herrera wrote:
> On 2023-Jan-20, Karl O. Pinc wrote:
>
> > On Fri, 20 Jan 2023 12:42:31 +0100
> > Alvaro Herrera wrote:
>
> > > Hmm, I didn't know that. I guess I can put it back. My own
> > > instinct i
On Fri, 20 Jan 2023 12:42:31 +0100
Alvaro Herrera wrote:
> On 2023-Jan-19, Karl O. Pinc wrote:
>
> > On Thu, 19 Jan 2023 11:03:53 -0600
> > "Karl O. Pinc" wrote:
> >
> > > Attached are 2 patches, a regular and a delta from your v4 revi
On Thu, 19 Jan 2023 11:03:53 -0600
"Karl O. Pinc" wrote:
> Attached are 2 patches, a regular and a delta from your v4 review:
>
> contrib_v5-delta.patch.txt
> contrib_v5.patch.txt
I left your appendix title unchanged: "Additional Supplied
Extensions and Modules
On Thu, 19 Jan 2023 13:35:17 +0100
Alvaro Herrera wrote:
> On 2023-Jan-18, Karl O. Pinc wrote:
>
> > Oops. Already sent a revised patch that includes starting each
> > module on a new page, for PDF output. I'll wait to rip that
> > out after review and start a new
On Tue, 17 Jan 2023 16:43:13 -0600
"Karl O. Pinc" wrote:
> It might be useful to add --nonet to the xsltproc invocation(s)
> in the Makefile(s). Just in case; to keep from retrieving
> stylesheets from the net. (If the option is not already there.
> I didn't look.)
>
On Wed, 18 Jan 2023 18:34:47 +0100
Alvaro Herrera wrote:
> On 2023-Jan-18, Karl O. Pinc wrote:
>
> > On Wed, 18 Jan 2023 13:30:45 +0100
> > Alvaro Herrera wrote:
> >
> > > Not related to this patch: it's very annoying that in the PDF
> > > output,
On Wed, 18 Jan 2023 13:25:57 +0100
Alvaro Herrera wrote:
> On 2023-Jan-02, Karl O. Pinc wrote:
> > Attached is a patch: contrib_v1.patch
> >
> > It modifies Appendix F, the contrib directory.
> >
> > It adds brief text into the titles shown in the
> > t
On Wed, 18 Jan 2023 13:30:45 +0100
Alvaro Herrera wrote:
> Not related to this patch: it's very annoying that in the PDF output,
> each section in the appendix doesn't start on a blank page -- which
> means that the doc page for many modules starts in the middle of a
> page were the previous one
On Tue, 17 Jan 2023 19:13:38 +0100
Brar Piening wrote:
> On 17.01.2023 at 14:12, Karl O. Pinc wrote:
> > If you're not willing to try I am willing to see if I can
> > produce an example to work from. My XSLT is starting to
> > come back.
>
> I'm certainly willin
On Tue, 17 Jan 2023 06:57:23 +0100
Brar Piening wrote:
> On 17.01.2023 at 02:05, Karl O. Pinc wrote:
> > Or maybe the right way is to set a mode at the very top,
> > the first apply-templates call, and not mess with the
> > built-in templates at all. (You'd write your o
On Mon, 16 Jan 2023 11:14:35 -0600
"Karl O. Pinc" wrote:
> On Sun, 15 Jan 2023 18:01:50 -0600
> "Karl O. Pinc" wrote:
>
> > Regards XSLT:
> >
> > I believe the XSLT needs work.
> In XSLT 1.0 there is no xml:default-mode. So I _think_
On Sun, 15 Jan 2023 18:01:50 -0600
"Karl O. Pinc" wrote:
> Regards XSLT:
>
> I believe the XSLT needs work.
> I believe that overriding the XSLT by copying the original and making
> modifications is the "wrong way" (TM). I think that the right way is
> t
On Sun, 15 Jan 2023 18:01:50 -0600
"Karl O. Pinc" wrote:
> Regards XSLT:
>
> I believe the XSLT needs work.
I also think that the XSLT should error and halt
when there's no id (in the expected places).
Instead of just giving a warning and keeping going. Otherwise
Hi Brar,
Here's my first review of the make_html_ids_discoverable.patch.
Overall:
To start with, I'd like to say I like the goal and how everything
works when the patch is applied. I was a bit skeptical, thinking that
the whole thing was going to be distracting when reading the docs or
On Sun, 15 Jan 2023 07:11:30 +0100
Brar Piening wrote:
> On 03.01.2023 at 01:00, Karl O. Pinc wrote:
> > Attached is a patch: contrib_v1.patch
> >
> > It modifies Appendix F, the contrib directory.
>
> Review:
> It adds a brief explanatory part to the
On Mon, 09 Jan 2023 15:18:18 -0500
Tom Lane wrote:
> Brar Piening writes:
> > On 09.01.2023 at 03:38, vignesh C wrote:
> >> There are couple of commitfest entries for this:
> >> https://commitfest.postgresql.org/41/4041/
> >> https://commitfest.postgresql.org/41/4042/ Can one of them be
> >>
On Mon, 09 Jan 2023 15:18:18 -0500
Tom Lane wrote:
> I pushed the ID-addition patch, with a few fixes:
>
> * AFAIK our practice is to use "-" never "_" in XML ID attributes.
> You weren't very consistent about that even within this patch, and
> the overall effect would have been to have no
On Mon, 9 Jan 2023 08:09:02 +0100
Brar Piening wrote:
> On 09.01.2023 at 03:31, vignesh C wrote:
> > The patch does not apply on top of HEAD as in [1], please post a
> > rebased patch:
> This one applies on top of 3c569049b7b502bb4952483d19ce622ff0af5fd6
> and the documentation build
On Sat, 7 Jan 2023 22:29:35 -0600
"Karl O. Pinc" wrote:
> The only way I could think of to review a patch
> that removes something is to report all the places
> I looked where a reference to the symlink might be.
I forgot to report that I also tried a `make install`
On Sat, 7 Jan 2023 19:56:08 -0600
"Karl O. Pinc" wrote:
> On Sat, 07 Jan 2023 18:38:25 -0500
> Tom Lane wrote:
>
> > "Karl O. Pinc" writes:
> > > This is a review of Peter's 2 patches. I see only 1 small
> > > problem. ...
&
On Sat, 7 Jan 2023 19:33:38 -0500
Joe Conway wrote:
> On 1/7/23 18:38, Tom Lane wrote:
> > "Karl O. Pinc" writes:
> >> This is a review of Peter's 2 patches. I see only 1 small
> >> problem.
The small problem is a reference to a deleted file.
Regar
On Sat, 07 Jan 2023 18:38:25 -0500
Tom Lane wrote:
> "Karl O. Pinc" writes:
> > This is a review of Peter's 2 patches. I see only 1 small problem.
> >
>
> > Looking at the documentation, a "postmaster" in the glossary is
> > defined
Hello,
This is a review of Peter's 2 patches. I see only 1 small problem.
+++
Looking at the documentation, a "postmaster" in the glossary is
defined as the controlling process. This works; it needs to be called
something. There is still a postmaster.pid (etc.) in
On Tue, 3 Jan 2023 21:35:09 +0100
Brar Piening wrote:
> On 02.01.2023 at 21:53, Karl O. Pinc wrote:
> > If the author will look over my version of the patch I believe it
> > can be approved and sent on to the committers.
>
> LGTM.
Approved for committer!
Regards,
Karl
Hi,
Attached is a patch: contrib_v1.patch
It modifies Appendix F, the contrib directory.
It adds brief text into the titles shown in the
table of contents so it's easier to tell what
each module does. It also suffixes [trusted] or [obsolete]
on the relevant titles.
I added the word
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:
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,
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
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 everywhe
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
On Tue, 10 Dec 2019 07:11:59 +0100
Pavel Stehule wrote:
> út 10. 12. 2019 v 0:03 odesílatel Karl O. Pinc napsal:
> > I also wonder whether all the trim_scale() tests
> > are now necessary, but not enough to make any suggestions.
> I don't think so tests should be minima
On Mon, 9 Dec 2019 21:04:21 +0100
Pavel Stehule wrote:
> I fixed almost all mentioned issues (that I understand)
If you don't understand you might ask, or at least say.
That way I know you've noticed my remarks and I don't
have to repeat them.
I have 2 remaining suggestions.
1) As previously
On Mon, 9 Dec 2019 12:15:22 -0600
"Karl O. Pinc" wrote:
> I've had some thoughts about the regression tests.
> Having written
> it out it seems like a lot of testing for such a simple function.
FYI.
I don't see trim_scale() needing such exhaustive testing because you'll
Hi Pavel,
I've had some thoughts about the regression tests.
It wouldn't hurt to move them to right after the
scale() tests in numeric.sql.
I believe your tests are covering all the code paths
but it is not clear just what test does what.
I don't see a lot of comments in the tests so I don't
Hi Pavel,
Thanks for your changes. More inline below:
On Sun, 8 Dec 2019 08:38:38 +0100
Pavel Stehule wrote:
> ne 8. 12. 2019 v 2:23 odesílatel Karl O. Pinc napsal:
> > On Mon, 11 Nov 2019 15:47:37 +0100
> > Pavel Stehule wrote:
> > > I implemented two functions
On Sun, 08 Dec 2019 13:57:00 -0500
Tom Lane wrote:
> "Karl O. Pinc" writes:
> > FWIW, I bumped around the Internet and looked at Oracle docs to see
> > if there's any reason why minscale() might not be a good function
> > name. I couldn't find any problems.
Hello Pavel,
On Mon, 11 Nov 2019 15:47:37 +0100
Pavel Stehule wrote:
> Here is a patch. It's based on Dean's suggestions.
>
> I implemented two functions - first minscale, second trim_scale. The
> overhead of second is minimal - so I think it can be good to have it.
> I started design with the
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 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 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 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 c
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
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
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.
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 causi
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
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 a
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
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.
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 docum
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&q
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" ->
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 th
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
Hi,
Doc patch, against master. Documents encode() and decode() base64
format.
Builds for me.
Attached: doc_base64_v1.patch
References RFC2045 section 6.8 to define base64.
Because encode() and decode() show up in both the string
functions section and the binary string functions section
I
Hi,
Attached is documentation patch: doc_client_min_messages_v1.patch
Document that INFO severity messages are always sent
to the client. This also adds hyperlinks to the
table of severity levels where those levels are
referenced in the docs.
The patch was discussed on the #postgresql IRC
100 matches
Mail list logo
