Re: Add id's to various elements in protocol.sgml - Mailing list pgsql-hackers

From Brar Piening
Subject Re: Add id's to various elements in protocol.sgml
Date
Msg-id 9767a9bb-5637-ec35-ba72-1faa7f50e72f@gmx.de
Whole thread Raw
In response to Re: Add id's to various elements in protocol.sgml  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Add id's to various elements in protocol.sgml  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
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 situation in the
docs currently looks like:

    element    | count
--------------+-------
  sect2        |   275
  sect3        |    94
  sect4        |    20
  simplesect   |    20
  varlistentry |  3976

Looking at this, I think that manually assigning an id to all ~400
sections currently lacking one to make them referable in a consistent
way is a bit of work but feasible.

Once we consitently have stable ids on section headers IMHO it makes
sense to also expose them as links. I'd probably also make the
stylesheet emit a non-terminating message/comment whenever it finds a
section without id in order to help keeping the layout consistent over time.

With regard to varlistentry I'd suggest to decide whether to add ids or
not on a case by case base. I already offered to add ids to long lists
upon request but I wouldn't want to blindly add ~4k ids that nobody
cares about. That part can also grow over time by people adding ids as
they deem them useful.

Any objections/thoughts?




pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: using extended statistics to improve join estimates
Next
From: Chapman Flack
Date:
Subject: Re: Add id's to various elements in protocol.sgml