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 hint.
Side project: I noticed that these new hover links don't appear in the
On 06.04.2023 at 11:06, Peter Eisentraut wrote:
On 04.04.23 21:52, Brar Piening 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 were changed
On 04.04.2023 at 16:54, Peter Eisentraut wrote:
First of all, it works very nicely and is very useful. Very welcome.
Thank you!
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
On 29.03.2023 at 06:52, Hayato Kuroda (Fujitsu) wrote:
FYI - my patch is pushed
Thanks!
Could you please rebase your patch?
Done and tested. Patch is attached.
Regards,
Brar
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index fcb53c6997..5c50347c58 100644
---
On 28.03.2023 at 00:11, Peter Smith wrote:
FYI, there is a lot of overlap between this last attachment and the
patches of Kuroda-san's current thread here [1] which is also adding
ids to create_subscription.sgml.
(Anyway, I guess you might already be aware of that other thread
because your new
On 23.03.2023 at 20:08, Brar Piening wrote:
Since the need for ids is starting to grow again (ecb696527c added an
id to a varlistentry in doc/src/sgml/ref/create_subscription.sgml)
I've also amended the add-needed-ids patch once again so that the
build does not fail after applying
On 24.03.2023 at 10:45, Alvaro Herrera wrote:
But why are there no anchors next to items on that page? For
example, how do I get the link for the "Meta Commands" subsection?
I somehow knew that responding from a crappy mobile phone e-mail client
will mess up the format and the thread...
For
On 24.03.2023 at 06:48, Brar Piening wrote:
Since (after tweaking the color) the general visual appearence looked
ok to me, I didn't bother with this any further.
Also, if we go on with this we'll probably end up in an almost
prototypical bikeshedding scenario where PostgreSQL itself
On 24.03.2023 at 05:09, Karl O. Pinc wrote:
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
On 23.03.2023 at 23:31, Karl O. Pinc wrote:
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
On 23.03.2023 at 10:35, 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.
Ok, I've created and tested a patch for this too.
Since the need for ids is starting to grow again
On 23.03.2023 at 10:35, 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 23.03.2023 at 04:09, Karl O. Pinc wrote:
You're quite right. I clearly didn't have my XSLT turned on. Importing
only works when templates are matched, not called by name.
Sorry for the extra work I've put you through.
No problem. As always I've learnt something which may help me in the
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
way" is to use the import mechanism.
It actually is not.
After quite some time trying to figure out why things
On 20.03.2023 at 19:47, Gregory Stark (as CFM) wrote:
Looks like a lot of good work was happening on this patch right up
until mid-February. Is there a lot of work left? Do you think you'll
have a chance to wrap it up this commitfest for this release?
Thanks for the ping.
I had another look
On 18.01.2023 at 06:50, Brar Piening wrote:
I'll give it a proper look this weekend.
It turns out I didn't get a round tuit.
... and I'm afraid I probably will not be able to work on this until
mid/end February so we'll have to move this to the next commitfest until
somebody wants to take
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
way" is to use the import mechanism.
I've attached a patch that "wraps" the section.heading template
and adds
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 willing to try but I'd appreciate an example in any case.
My XSLT skills are mostly learning by doing
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 own
"postgres-mode" templates the same way, to "wrap"
and call the default templates.)
Think
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:
The patch applies cleanly (1334b79a35 - 2023-01-14 18:05:09 +0900).
It adds a brief explanatory part to the headers of all contrib modules
which I
On 12.01.2023 at 00:05, Tom Lane wrote:
Peter Eisentraut writes:
Any reason the new ids in create_database.sgml deviate from the normal
naming schemes used everywhere else? Is it to preserve the existing
create-database-strategy? Maybe we should rename that one and make the
new ones
On 10.01.2023 at 06:28, Brar Piening wrote:
I'll repost a rebased version of the styling patch in a minute.
After checking that there's no need for rebasing I'm reposting the
original patch here, to make cfbot pick it up as the latest one in a
somewhat screwed up thread mixing two patches
On 09.01.2023 at 23:28, Karl O. Pinc wrote:
On Mon, 09 Jan 2023 15:18:18 -0500
Tom Lane wrote:
It's probably going to be necessary to have follow-on patches,
because I'm sure there is stuff in the pipeline that adds more
ID-less tags. Or do we have a way to create warnings about that?
I am
On 09.01.2023 at 21:18, Tom Lane wrote:
It's not great to have multiple CF entries pointing at the same email
thread --- it confuses both people and bots. Next time please split
off a thread for each distinct patch.
I agree. I had overestimated the cfbot's ability to handle branched
threads.
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 closed?
I've split the initial patch into two parts upon Álvaro's request in [1]
so that we can
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.
Thanks!
Brar
On 06.12.2022 at 19:11, Brar Piening wrote:
The current statistics for docbook elements with/without ids after
applying the patch are the following:
Somehow my e-mail client destroyed the table. That's how it was supposed
to look like:
name | with_id | without_id | id_coverage
On 06.12.2022 at 18:59, Brar Piening wrote:
On 06.12.2022 at 09:38, Alvaro Herrera wrote:
I would welcome separate patches: one to add the IDs, another for the
XSL/CSS stuff. That allows us to discuss them separately.
I'll send two patches in two separate e-mails in a moment.
This is patch
On 06.12.2022 at 09:38, Alvaro Herrera wrote:
I care. The problem last time is that we were in the middle of the last
commitfest, so we were (or at least I was) distracted by other stuff.
Ok, thanks. That's appreciated and understood.
Looking at the resulting psql page,
On 06.12.2022 at 01:55, Ian Lawrence Barwick wrote:
Oh, now you mention it, I vaguely recall seeing those. However the thread
stalled back in March and the patches don't seem to have made it to a
CommitFest entry.
Yes, my patches added quite a few ids and also some xsl/css logic to
make them
On 09.03.2022 at 20:43, Brar Piening wrote:
Attached is a pretty huge patch that adds ids to all sections and all
the varlistentries where the containing variablelist already had at
least one id (plus a few additional ones that I stumbled upon and
deemed useful). It also adds html links next
On 02.03.2022 at 18:54, Chapman Flack wrote:
Perhaps there are a bunch of variablelists where no one cares about
linking to any of the entries.
So maybe a useful non-terminating message to add eventually would
be one that identifies any varlistentry lacking an id, with a
variablelist where at
On 02.03.2022 at 10:37, Peter Eisentraut wrote:
I have applied the part of your patch that adds the id's. The
discussion about the formatting aspect can continue.
Thank you!
I've generated some data by outputting the element name whenever a
section or varlistentry lacks an id. That's how the
On Mar 01, 2022 at 18:27, Brar Piening wrote:
On Feb 28, 2022 at 21:06, Chapman Flack wrote:
I think that in other recent examples I've seen, there might be
(something like a) consensus forming around the Unicode LINK SYMBOL
rather than # as the symbol for such things.
I intentionally opted
On Feb 28, 2022 at 21:06, Chapman Flack wrote:
I think that in other recent examples I've seen, there might be
(something like a) consensus forming around the Unicode LINK SYMBOL
rather than # as the symbol for such things.
I intentionally opted for an ASCII character as that definitely won't
On Feb 25, 2022 at 06:36, Brar Piening wrote:
The major problem in that regard would probably be my lack of
XSLT/docbook skills but if no one can jump in here, I can see if I can
make it work.
Ok, I've figured it out.
Attached is an extended version of the patch that changes the XSL and
CSS
On 28.02.2022 at 10:24, Peter Eisentraut wrote:
On 28.02.22 09:41, Brar Piening wrote:
On Feb 25, 2022 at 14:31, Peter Eisentraut wrote:
I think that kind of stuff would be added in via the web site
stylesheets, so you wouldn't have to deal with XSLT at all.
True for the CSS but adding
On Feb 25, 2022 at 14:31, Peter Eisentraut wrote:
I think that kind of stuff would be added in via the web site
stylesheets, so you wouldn't have to deal with XSLT at all.
True for the CSS but adding the HTML (#)
will need either XSLT or Javascript.
On 24.02.2022 at 17:07, Brar Piening wrote:
On 24.02.2022 at 16:46, Alvaro Herrera wrote:
Would it be possible to create such anchor links as part of the XSL
stylesheets for HTML?
I'll investiogate our options and report back.
Yes, that would be possible. In fact appending a link
On 24.02.2022 at 16:46, Alvaro Herrera wrote:
On 2022-Feb-24, Dagfinn Ilmari Mannsåker wrote:
Peter Eisentraut writes:
Is there a way to obtain those URLs other than going into the HTML
sources and checking if there is an anchor near where you want go?
I use the jump-to-anchor extension:
On 20.12.2021 at 16:09, Robert Haas wrote:
As a data point, this is something I have also wanted to do, from time
to time. I am generally of the opinion that any place the
documentation has a long list of things, which should add ids, so that
people can link to the particular thing in the list
On Dec 17, 2021 at 08:13, Peter Eisentraut wrote:
On 15.12.21 16:59, Brar Piening wrote:
On Dec 15, 2021 at 15:49, Alvaro Herrera wrote:
On 2021-Dec-15, Brar Piening wrote:
Since I can't argue towards some general utility for the xreflabels
and don't have any other solid argument in favor
On Dec 15, 2021 at 15:49, Alvaro Herrera wrote:
On 2021-Dec-15, Brar Piening wrote:
Since I can't argue towards some general utility for the xreflabels
and don't have any other solid argument in favor of adding more, I
will remove them from my current patch but leave the existing ones
intact
On Dec 14, 2021 at 20:47, Alvaro Herrera wrote:
Hmm, I think we tend to avoid xreflabels; see
https://www.postgresql.org/message-id/8315c0ca-7758-8823-fcb6-f37f9413e...@2ndquadrant.com
Ok, thank you for the hint.
I added them because doesn't automatically generate
labels and they were
When working with the Frontend/Backend Protocol implementation in Npgsql
and discussing things with the team, I often struggle with the fact that
you can't set deep links to individual message formats in the somewhat
lengthy html docs pages.
The attached patch adds id's to various elements in
Amit Kapila schrieb:
On Mon, Jun 21, 2021 at 4:13 PM Brar Piening wrote:
Amit Kapila wrote:
After looking at the docs once again I have another minor amendment (new
patch attached).
+The value of the column, eiter in binary or in text format.
Typo. /eiter/either
Fixed
Amit Kapila wrote:
On Mon, Jun 21, 2021 at 12:26 PM Brar Piening wrote:
Hello Hackers,
while amending Npgsql to account for the Logical Streaming Replication
Protocol changes in PostgreSQL 14 I stumbled upon two documentation
inaccuracies in the Logical Replication Message Formats
Hello Hackers,
while amending Npgsql to account for the Logical Streaming Replication
Protocol changes in PostgreSQL 14 I stumbled upon two documentation
inaccuracies in the Logical Replication Message Formats documentation
Jeff Davis wrote:
Attached a simple patch that enforces an all-ASCII restore point name
rather than documenting the possibility of non-ASCII text.
+1
This is probably the best solution because it gives guarantees to the
client without causing compatibility issues with old clients.
Thanks!
hout over-engineering the problem or causing any
backwards-compatibility issues.
Regards,
Brar Piening
Bruce Momjian wrote:
>> Good point. The reporter was assuming the data would come to the client
>> in the bytea output format specified by the GUC, e.g. \x..., so that
>> doesn't happen either. As I said before, it is more raw bytes, but we
>> don't have an SQL data type for that.
> I did some
While implementing streaming replication client functionality for Npgsql
I stumbled upon a minor documentation error at
https://www.postgresql.org/docs/current/protocol-replication.html
The "content" return value for the TIMELINE_HISTORYcommand is advertised
as bytea while it is in fact raw ASCII
Brar Piening wrote:
> This is certainly a minor problem
After thinking about it a little more I think that at least the fact
that even the row description message advertises the content as bytea
could be considered as a bug - no?
53 matches
Mail list logo
