RE: [16Beta1][doc] pgstat: Track time of the last scan of a relation - Mailing list pgsql-hackers

From Shinoda, Noriyoshi (PN Japan FSIP)
Subject RE: [16Beta1][doc] pgstat: Track time of the last scan of a relation
Date
Msg-id DM4PR84MB1734F413279B051DA0599E64EE499@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: [16Beta1][doc] pgstat: Track time of the last scan of a relation  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
Hi, Thanks for your comment.
As you say, it would be difficult to unify the data types in all documents right now.
The patch I attached the other day unifies only the newly added columns in monitoring.sgml to "timestamp with time
zone".

Regards,
Noriyoshi Shinoda
-----Original Message-----
From: David Rowley <dgrowleyml@gmail.com> 
Sent: Wednesday, May 31, 2023 3:14 PM
To: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>; dpage@pgadmin.org; andres@anarazel.de; bruce@momjian.us;
vik@postgresfriends.org
Subject: Re: [16Beta1][doc] pgstat: Track time of the last scan of a relation

On Wed, 31 May 2023 at 15:57, Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com> wrote:
> According to the documentation [2], the data type of the columns added to these views is 'timestamptz'.
> However, columns of the same data type in pg_stat_all_tables.last_vacuum, last_analyze and other tables are unified
to'timestamp with time zone'. The attached patch changes the data type of the added column from timestamptz to
timestampwith time zone.
 

I agree that it would be good to make those consistently use timestamp with time zone for all columns of that type in
thedocs for pg_stat_all_tables.
 

More generally, it might be good if we did it for the entire docs:

doc $ git grep "<type>timestamptz</type>" | wc -l
17
doc $ git grep "<type>timestamp with time zone</type>" | wc -l
74

Clearly "timestamp with time zone" is much more commonly used.

The bar is probably set a bit higher for changing the longer-established ones, however.

David

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Docs: Encourage strong server verification with SCRAM
Next
From: Greg Stark
Date:
Subject: Re: Avoiding another needless ERROR during nbtree page deletion