Re: CancelRequest(F) documentation.

[Magnus Hagander]

On Mon, 13 Oct 2025 at 11:57, Jelte Fennema-Nio  wrote:

> On Tue Oct 7, 2025 at 6:08 PM CEST, Dmitry Igrishin wrote:
> > CancelRequest(F) documentation at
> >
> https://www.postgresql.org/docs/18/protocol-message-formats.html#PROTOCOL-MESSAGE-FORMATS-CANCELREQUEST
> > seems to be inconsistent for protocol 3.2. It is stated here that the
> > length of the message is always 16 bytes (specified as Int32(16)),
> > however the maximum message length actually depends on the secret key
> > length (which can be up to 256 bytes, as also stated in the
> > documentation.)
>
> Good catch. Attached is a patch that fixes this.
>

Thanks, pushed!

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

BPCHAR description in 8.3. Character Types is misleading and incomplete

[PG Doc comments form]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/18/datatype-character.html
Description:

The description of BPCHAR in section 8.3. Character Types is misleading and
incomplete.
The first problem is that, contrary to table 8.4, BPCHAR is not actually
blank-trimmed. The wording "as-if-blank-trimmed" or "blank-ignoring" may be
better suited here. The following query explains the problem:

SELECT bpchar_val, length(bpchar_val) as bplen, concat('[', bpchar_val, ']')
as bpbrack
, varchar_val, length(varchar_val) as vclen, concat('[',
varchar_val, ']') as vcbrack
FROM (VALUES
('abc   '::bpchar, 'abc   '::varchar),
('abc   '::bpchar, 'abc'::varchar),
('abc'::bpchar, 'abc   '::varchar),
('abc'::bpchar, 'abc'::varchar))
AS bpchar_test (bpchar_val, varchar_val)
WHERE bpchar_val = varchar_val;

As can be seen, it returns four rows (so, it indeed treats values that
differ only in number of trailing spaces as equal, regardless of the type on
the other side, and the length of bpchar_val is always 3 in all 4 rows -
trailing spaces are ignored in comparison. But the bpbrack column shows that
actual value is NOT trimmed: two of four rows have '[abc   ]' value (with 3
spaces before the closing bracket).
The example above also illustrate the need of more detailed explanation of
how BPCHAR actually behaves in different situation, particularly, in which
contexts trailing blanks are ignored (comparison, length, what else?) and in
which they are still significant (displaying, client interfaces,
concatenation, what else?).

The second problem is that 'Tip' before the example 8.1 mentions only three
types, also in a misleading way: 'There is no performance difference among
these three types' - as if there were only 3, not 4 distinct types.

BPCHAR description in 8.3. Character Types is misleading and incomplete

[David G. Johnston]

On Thursday, October 16, 2025, Sergei Katkovsky 
wrote:


> Manual addition is not padding, If it were, then VARCHAR would also be
> "blank-padded", because you can manually add trailing blanks to values
> of this type too. But of course it isn't.
>

The spaces added to the end of a bpchar manually can and are considered
“padding” - or “present but lack semantic/value significance”. The reason
they are not padding for varchar is that such spaces are considered part of
the stored value from a semantic perspective.

Think of padding as a noun, not a verb.  “The value contains padding”.
Not, “ I am padding the value”.

And yes, this is intended as a way to make the name of the type and its
behavior consistent.  You sorta have to want it to work/make sense; not
fight it on minor nuance.

David J.

Re: in the different schema ，the sequence name is same， and a table's column definition use this sequence,so，how can I identify sequence's schema name by system view/table:

[David G. Johnston]

On Wednesday, October 1, 2025, yanliang lei  wrote:
>
> dbversion180=# create table schema_1.test_tab_100(c1 int default
> nextval('seq_xx_yy'));
>

Since you didn’t schema qualify the sequence name every single time a
default value is created the sequence will be looked up anew.  The stored
expression is not associated with any specific object.

This is also why there is a separate step to mark a sequence as being owned
by a table.  That establishes a dependency that this textual form is unable
to do.

David J.

Re: Documentation improvement patch

[Oleg]

Thank you for your feedback, Daniel.

My thoughts are below:

/- Change the definition of a replication slot. + Changes the definition 
of a replication slot. Reading this page it seems we are mixing tense in 
many places, some say "Change the" and "Read some" and elsewhere we use 
"Drops the". Maybe a more holistic approach would be better for this 
page to improve consistency? /I agree, let's add "s" in all cases for the sake of consistency.


/- Not enabled by default because it is resource intensive. + Not 
enabled by default because it is resource-intensive. We use both 
spellings in multiple places, shouldn't all be changed?/


Agreed, changing all instances to "resource-intensive".

/- COPY and other file-access functions. + the 
COPY command and file-access functions. ... - 
COPY and other file-access functions. + the 
COPY command and file-access functions. ... - 
COPY and other functions which allow executing a + 
the COPY command and functions, which allow executing 
a I'm not sure about these, I think we use COPY without the the "the 
COPY command" decoration in many places so I think it's more consistent 
like this. /I actually think we should add the decoration here because "COPY and other file-access functions"

sounds a bit confusing since COPY is not a file-access function and we seem to 
put it in the list. Even though I
agree that everybody knows COPY is a command, not a function.

/- to call functions defined in the standard internal library, by using 
an + to call functions defined in the standard internal function library 
by using an interface similar to their SQL signature. Isn't it a bit 
redundant to say "internal function library" when we are already talking 
about function definitions?/


I agree that it may seem redundant, I added "function" here for the sake of 
consistency with lines 1829/1830 (if applied to the master branch)
where the documentation mentions "standard internal*function* library".

Please, let me know what you think of the last two points for me to send the 
updated patch.

--
Oleg Sibiryakov

On 10.10.2025 10:15, Daniel Gustafsson wrote:

On 10 Sep 2025, at 09:54, Oleg wrote:

Dear all,
I have prepared a patch containing some minor inconsistencies in the 
documentation. Please, take a look.
I will be looking forward to your feedback.

Thanks for the patch, while most of these are obvious improvements I have a few
comments on some:


-   Change the definition of a replication slot.
+   Changes the definition of a replication slot.
Reading this page it seems we are mixing tense in many places, some say "Change
the" and "Read some" and elsewhere we use "Drops the".  Maybe a more holistic
approach would be better for this page to improve consistency?


-   Not enabled by default because it is resource intensive.
+   Not enabled by default because it is resource-intensive.
We use both spellings in multiple places, shouldn't all be changed?


-   COPY and other file-access functions.
+   the COPY command and file-access functions.
 ...
-   COPY and other file-access functions.
+   the COPY command and file-access functions.
 ...
-   COPY and other functions which allow executing a
+   the COPY command and functions, which allow 
executing a
I'm not sure about these, I think we use COPY without the the "the COPY
command" decoration in many places so I think it's more consistent like this.


- to call functions defined in the standard internal library, by using an
+ to call functions defined in the standard internal function library by 
using an
   interface similar to their SQL signature.
Isn't it a bit redundant to say "internal function library" when we are already
talking about function definitions?


The patch shall be applied to the REL_18_STABLE branch.

As you mentioned downthread, this is also for master.  Our workflow is to
always apply to master and backpatch from there.

--
Daniel Gustafsson

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[David G. Johnston]

On Thursday, October 16, 2025, Sergei Katkovsky 
wrote:

> > I don't understand why any of these variants are better than the
> > original wording "blank-padded".  That has the non-negligible
> > advantage of corresponding to the type name, and furthermore
> > appears in many other places in our docs and source code.
>
> The wording for BPCHAR (not to be confused with BPCHAR(N) is already
> "blank-trimming", not "blank-padded". And "blank-padded" is probably
> the least correct wording variant for BPCHAR, because this type has
> unlimited length and it's impossible to pad to the infinity.


A given value has a finite length and there is just no restriction on what
that length is.  All trailing spaces in the input are considered padding
for purposes of comparison i.e., manually padding is added by the user as
opposed to the system.

So bpchar(n) is automatically blank padded to a total length for a value of
n characters.  bpchar also has padding blanks but they must be manually
inserted during value creation.

I would leave the note of blank-padded for both and just point out the
automatic vs manual distinction.

David J.

Re: doc: Fix missing closing parentheses in monitoring.sgml

[Daniel Gustafsson]

> On 7 Oct 2025, at 14:27, Shinya Kato  wrote:

> Attached is a doc-only fix that adds a missing closing parenthesis in
> monitoring.sgml (pg_stat_progress_analyze: delay_time).

Thanks, will fix (with a backpatch to 18).

--
Daniel Gustafsson

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[Sergei Katkovsky]

On Thu, Oct 16, 2025 at 11:18 PM David G. Johnston
 wrote:

>> > Think of padding as a noun, not a verb.  “The value contains padding”.  
>> > Not, “ I am padding the value”.
>
> In PostgreSQL the behavior and stored contents/representation of a value are 
> not influenced by a type modifier.  It is only used during input to perform 
> some either or both a validation or transformation.  Here, when present, it 
> performs a padding transform.  But present or absent, trailing spaces, if 
> any, are considered padding.  The prose for the section talk about the two 
> key pieces: (n) imposes a length limit while also transforming an input by 
> adding padding spaces.  The non-n case has unlimited length and no 
> transformation.  Post-construction, all trailing spaces are treated as 
> padding.

Am I right that your reasoning, when expanded, turns into "BPCHAR is
blank-padded, where '-padded' means (Definition 1) that its values may
have trailing blanks, which, if present, are considered 'padding'
(Definition 2), which, in its turn, means a sequence of blanks
insignificant in some contexts (Definition 3)"? Yes, technically it is
correct, provided that others accept all those definitions. But don't
you think that in the documentation we should, whenever possible, use
words in their most commonly understood meanings? I'm not a language
expert, but I have never seen 'padded' in the sense different from
'something added to gain some needed size/shape/etc'. This is
anecdotal evidence, of course, so I can be wrong, but could you come
up with a counterexample?  Even in the PostgreSQL docs for BPCHAR(n)
'padded' means 'with spaces added up to n' ('values of type character
will be space-padded', 'Values of type character are physically padded
with spaces' - as a verb, not a noun, btw). I'm afraid that adding
another meaning to the word 'padded' in the same text will cause even
more confusion.


With best regards,
Sergei Katkovskii

Re: in the different schema ，the sequence name is same， and a table's column definition use this sequence,so，how can I identify sequence's schema name by system view/table:

[Greg Sabino Mullane]

On Wed, Oct 1, 2025 at 6:04 AM yanliang lei  wrote:

>  the column c1 in the schema_1.test_tab_100 is associated with which
> sequence ?? *schema_1*.seq_xx_yy or *public*.seq_xx_yy??
>

This is better asked on the pgsql-general mailing list, but the short
answer is that you have to look at your search_path as well. Since you just
created schema_1, and public is in your search_path, a plain seq_xx_yy is
the one from the public schema. To see the fully-qualified name, run:

SET search_path = pg_catalog;

before issuing your select from information_schema.columns

Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

Re: in the different schema ，the sequence name is same， and a table's column definition use this sequence,so，how can I identify sequence's schema name by system view/table:

[David G. Johnston]

On Wednesday, October 1, 2025, David G. Johnston 
wrote:

> On Wednesday, October 1, 2025, yanliang lei  wrote:
>>
>> dbversion180=# create table schema_1.test_tab_100(c1 int default
>> nextval('seq_xx_yy'));
>>
>
> Since you didn’t schema qualify the sequence name every single time a
> default value is created the sequence will be looked up anew.  The stored
> expression is not associated with any specific object.
>
> This is also why there is a separate step to mark a sequence as being
> owned by a table.  That establishes a dependency that this textual form is
> unable to do.
>
>
 Ignore that…we do stored the parsed representation which nominally has the
schema recorded, it’s just that the text serialization it too “helpful” by
inspecting the search_path and only produces the schema prefix if it would
be necessary to resolve the reference.

David J.

Error in example

[PG Doc comments form]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/18/ddl-generated-columns.html
Description:

On page https://www.postgresql.org/docs/current/ddl-generated-columns.html :

In the example "CREATE TABLE people" ...,
the line "GENERATED ALWAYS AS ..." is missing the mandatory suffix word
"STORED".


Regards,
fjf2002

Re: CancelRequest(F) documentation.

[Jelte Fennema-Nio]

On Tue Oct 7, 2025 at 6:08 PM CEST, Dmitry Igrishin wrote:

CancelRequest(F) documentation at
https://www.postgresql.org/docs/18/protocol-message-formats.html#PROTOCOL-MESSAGE-FORMATS-CANCELREQUEST
seems to be inconsistent for protocol 3.2. It is stated here that the
length of the message is always 16 bytes (specified as Int32(16)),
however the maximum message length actually depends on the secret key
length (which can be up to 256 bytes, as also stated in the
documentation.)


Good catch. Attached is a patch that fixes this.
From 5506c574e976eb40174820668a00f02e9b4b62f4 Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio 
Date: Mon, 13 Oct 2025 11:52:22 +0200
Subject: [PATCH v1] docs: Fix protocol version 3.2 message format of
 CancelRequest

Since protocol version 3.2 the CancelRequest does not have a fixed size
length anymore. The protocol docs still listed the length field to be a
constant number though. This fixes that.

Reported-by: Dmitry Igrishin 
Backpatch-through: 18
---
 doc/src/sgml/protocol.sgml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index b5395604fb8..9d755232873 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -4327,7 +4327,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
 
  
   
-   Int32(16)
+   Int32

 
  Length of message contents in bytes, including self.

base-commit: 7a662a46ebf74e9fa15cb62b592b4bf00c96fc94
-- 
2.51.0

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[Jeff Davis]

On Tue, 2025-10-14 at 12:14 +, PG Doc comments form wrote:
> The description of BPCHAR in section 8.3. Character Types is
> misleading and
> incomplete.

Hi,

There was a previous discussion here:

https://www.postgresql.org/message-id/E1odZyZ-g2-AE%40gemulon.postgresql.org

> The first problem is that, contrary to table 8.4, BPCHAR is not
> actually
> blank-trimmed. The wording "as-if-blank-trimmed" or "blank-ignoring"
> may be
> better suited here. The following query explains the problem:

Correct, it does not actually trim the blanks before storing. The
paragraph below the table clarifies: "If bpchar lacks a length
specifier, it also accepts strings of any length, but trailing spaces
are semantically insignificant."

I think "blank-insignificant" is slightly better than "blank-ignoring".

> The second problem is that 'Tip' before the example 8.1 mentions only
> three
> types, also in a misleading way: 'There is no performance difference
> among
> these three types' - as if there were only 3, not 4 distinct types.

Thank you.

Please take a look at the attached patch. If you'd like your name
included in the commit, please send it as you'd like it to appear.

Regards,
Jeff Davis

diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index b81d89e2608..ed9c1cba211 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -1178,7 +1178,7 @@ SELECT '52093.89'::money::numeric::float8;


 bpchar
-variable unlimited length, blank-trimmed
+variable unlimited length, blank-insignificant


 text
@@ -1298,7 +1298,7 @@ SELECT '52093.89'::money::numeric::float8;
 

 
- There is no performance difference among these three types,
+ There is no performance difference among these four types,
  apart from increased storage space when using the blank-padded
  type, and a few extra CPU cycles to check the length when storing into
  a length-constrained column.  While

[DOCS] document ShareLock behaviour when using a deferred unique index

[Alpha Shuro]

The logs that were printed by Postgres
when enforcing deferred unique indexes were misleading.

This change should make it easier to understand or investigate
when users see the `waits for ShareLock` log entry
---
 doc/src/sgml/mvcc.sgml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 049ee75a4ba..4e36c59776a 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -1003,32 +1003,37 @@ ERROR:  could not serialize access due to read/write 
dependencies among transact
   

 SHARE (ShareLock)


 
  Conflicts with the ROW EXCLUSIVE,
  SHARE UPDATE EXCLUSIVE, SHARE ROW
  EXCLUSIVE, EXCLUSIVE, and
  ACCESS EXCLUSIVE lock modes.
  This mode protects a table against concurrent data changes.
 

 
  Acquired by CREATE INDEX
  (without CONCURRENTLY).
+
+ It is also acquired when enforcing a DEFERRED UNIQUE INDEX:
+ If a transaction detects another transaction that might cause
+ a potential conflict, it waits for the other transaction to complete,
+ by acquiring a ShareLock on the other transaction's transaction id.
 

   
--
2.51.0

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[David G. Johnston]

On Thursday, October 16, 2025, Sergei Katkovsky 
wrote:

> On Thu, Oct 16, 2025 at 11:18 PM David G. Johnston
>  wrote:
>
> >> > Think of padding as a noun, not a verb.  “The value contains
> padding”.  Not, “ I am padding the value”.
> >


> I'm afraid that adding
> another meaning to the word 'padded' in the same text will cause even
> more confusion.
>

I’m just trying to phrase the documentation for bpchar so that the “bp”,
which stands for “blank-padded”, is justified.  The generic term for the
trailing spaces here is padding in the noun sense.

I do understand the terminology confusion with the verb padding.  And see
why “trimmed” is actively confusing.  The prose probably needs to resolve
this - and technically does from what I’m reading.

You may wish to move on from critiquing my suggested changes and instead
propose something concrete of your own.  Provide a third choice besides
status-quo and my option.

Though I’m doubtful there is a nice precise hyphenated word to be found
here for “treats any trailing spaces as being semantically insignificant”.

David J.

in the different schema ，the sequence name is same， and a table's column definition use this sequence,so，how can I identify sequence's schema name by system view/table:

[yanliang lei]

hi ，everyone，
my postgresql version is 18.0,
in the different schema ，the sequence name is same， and a table‘s  column 
definition use  this  sequence，
so，how can I identify sequence's schema name by system view/table?


the following is example:


[pg180@kunpeng3 ~]$ psql -d postgres -U pg180 -p 5418
psql (18.0)
输入 "help" 来获取帮助信息.
postgres=# create database dbversion180
postgres-# ;
CREATE DATABASE
postgres=# \c dbversion180 ;
您现在已经连接到数据库 "dbversion180",用户 "pg180".
dbversion180=# create schema schema_1;
CREATE SCHEMA
dbversion180=# create schema schema_2;
CREATE SCHEMA
dbversion180=# create sequence public.seq_xx_yy;
CREATE SEQUENCE
dbversion180=# create table schema_1.test_tab_100(c1 int default 
nextval('seq_xx_yy'));
CREATE TABLE
dbversion180=# SELECT table_schema,table_name,column_name,column_default FROM 
information_schema.columns WHERE column_default LIKE 'nextval%' and 
table_name='test_tab_100';
 table_schema | table_name | column_name | column_default
--+--+-+
 schema_1 | test_tab_100 | c1 | nextval('seq_xx_yy'::regclass) >> We know: 
this "seq_xx_yy" sequence's schema is public.
(1 行记录)
dbversion180=# select * from pg_sequences;
 schemaname | sequencename | sequenceowner | data_type | start_value | 
min_value | max_value | increment_by | cycle | cache_size | last_value
+--+---+---+-+---+-+--+---++
 public | seq_xx_yy | pg180 | bigint | 1 | 1 | 9223372036854775807 | 1 | f | 1 |
(1 行记录)
dbversion180=# create sequence schema_1.seq_xx_yy;
CREATE SEQUENCE
dbversion180=# SELECT table_schema,table_name,column_name,column_default FROM 
information_schema.columns WHERE column_default LIKE 'nextval%' and 
table_name='test_tab_100';
 table_schema | table_name | column_name | column_default
--+--+-+
 schema_1 | test_tab_100 | c1 | nextval('seq_xx_yy'::regclass)
(1 行记录)
dbversion180=#
dbversion180=# select version();
  version
---
 PostgreSQL 18.0 on aarch64-unknown-linux-gnu, compiled by gcc (GCC) 7.3.0, 
64-bit
(1 行记录)


dbversion180=# 


 --->> how can I identify sequence's schema name by  system 
view/table:
 the column c1 in the schema_1.test_tab_100 is associated with which sequence 
?? schema_1.seq_xx_yy or public.seq_xx_yy??




thanks !

Error in example

[David G. Johnston]

On Monday, September 29, 2025, PG Doc comments form 
wrote:

> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/18/ddl-generated-columns.html
> Description:
>
> On page https://www.postgresql.org/docs/current/ddl-generated-columns.html
> :
>
> In the example "CREATE TABLE people" ...,
> the line "GENERATED ALWAYS AS ..." is missing the mandatory suffix word
> "STORED".
>
>
Read the sentence immediately following that example.

As of version 18 it is no longer mandatory.

David J.

Re: Can not close psql

[Tom Lane]

PG Doc comments form  writes:
> I was connected to database via `psql` then I rebooted DB. I was not able to
> disconnect from terminal after that. Only whole window close helped.

A documentation comment is a very poor way to submit a trouble
report...

> FATAL:  terminating connection due to administrator command
> SSL connection has been closed unexpectedly
> The connection to the server was lost. Attempting reset:
> ^C^C^C^C

Hmm.  When I try this I get either

postgres=# \d
FATAL:  terminating connection due to administrator command
SSL connection has been closed unexpectedly
The connection to the server was lost. Attempting reset: Failed.
!?> 

or

postgres=# \d
FATAL:  terminating connection due to administrator command
SSL connection has been closed unexpectedly
The connection to the server was lost. Attempting reset: Succeeded.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: 
off, ALPN: postgresql)
postgres=# 

(depending on whether I restarted the server yet), with pretty
much no delay.  You'll need to provide a lot more context about
your setup if you want useful help.  What's the platform?  Is
the server on the same machine as psql, or remote?  What
connection options are you using besides SSL?  What OpenSSL
version is psql using?  For that matter, which psql version
is it?

https://wiki.postgresql.org/wiki/Guide_to_reporting_problems

regards, tom lane

Re: Confusion in section 8.7.3. Type Safety

[David Rowley]

On Tue, 23 Sept 2025 at 20:59, PG Doc comments form
 wrote:
> Page: https://www.postgresql.org/docs/17/datatype-enum.html
> Description:
>
> In section 8.7.3. Type Safety one can observe a the following statement in
> the examples.
>
> INSERT INTO holidays(num_weeks,happiness) VALUES (2, 'sad');
>
> This is somewhat confusing since type happiness doesn't contain 'sad'. I
> would suggest to remove the statement or to add an enum 'sad' in type
> happiness.

Thank you for the report. I think you might have missed that this
section is demonstrating that the statement does not work due to the
column's type not containing an enum value for 'sad' and that enum
values are specific to the particular enum, rather than global to all
enum types, as one *could* have assumed.

Your proposed modification would make the bogus INSERT statement work,
which would defeat the purpose of the section demonstrating that it
doesn't work.

David

Re: Can not close psql

[David G. Johnston]

On Thursday, October 16, 2025, PG Doc comments form 
wrote:

> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/18/app-psql.html
> Description:
>
> Hello.
> I was connected to database via `psql` then I rebooted DB. I was not able
> to
> disconnect from terminal after that. Only whole window close helped.


> It would be nice if `psql` allows to disconnect from console if a
> connection
> to database was lost.
>

Seems like this would be better reported as an actual bug.  Not as comments
related to the effectiveness of the documentation.

David J.