Subject: Documentation of pg_badkend_pid and stats functions

From: Jim Nasby <[email-masked]>
Date: Thu, 12 Apr 2007 08:54:24 -0400

Two questions: Why is pg_backend_pid documented with the stats  
functions (9.19 System Information Functions) seems more logical.

Also, I can see mentioning the stats functions in the monitoring  
section, but shouldn't they actually be documented in with the rest  
of the functions?
--
Jim Nasby                                            [email-masked]
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

---

From: Jim Nasby <[email-masked]>
Date: Sun, 6 May 2007 10:12:22 -0500

> section, but shouldn't they actually be documented in with the rest  

No comments? Does that mean if I write up a patch it'll be accepted?
--
Jim Nasby                                            [email-masked]
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 6 May 2007 12:44:50 -0400 (EDT)

> No comments? Does that mean if I write up a patch it'll be accepted?

Yea, I was wondering about that.  I think the best idea would be to
reference the backend functions from the main functions page, rather
than move them.

-- 
  Bruce Momjian  <[email-masked]>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---

From: Jim Nasby <[email-masked]>
Date: Mon, 7 May 2007 11:03:08 -0500

> reference the backend functions from the main functions page, rather

Well, pg_backend_pid makes no sense being in with the stats  
functions, so I'll move it. I'll just include references to the other  
stuff.
--
Jim Nasby                                            [email-masked]
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

---

From: Jim Nasby <[email-masked]>
Date: Sun, 13 May 2007 15:55:54 -0500

On May 7, 2007, at 11:03 AM, Jim Nasby wrote:
> functions, so I'll move it. I'll just include references to the  
> other stuff.

Turns out it didn't really make much more sense to move  
pg_backend_pid either, so I went with Bruce's original idea.

---

From: Tom Lane <[email-masked]>
Date: Sun, 13 May 2007 18:48:01 -0400

Jim Nasby <[email-masked]> writes:
>     <title>System Information Functions</title>
  
>     <para>
> +    In addition to the functions listed in this section, there are a number of
> +    functions related to the statistics system that also provide system
> +    information. See <xref linkend="monitoring-stats-views"> for more
> +    information.
> +   </para>

Surely a section should not *begin* with a cross-reference to someplace
else.

			regards, tom lane

---

From: "Jim C. Nasby" <[email-masked]>
Date: Sun, 13 May 2007 17:59:59 -0500

> Surely a section should not *begin* with a cross-reference to  

My concern is that folks will see the table right below it, not find
what they're looking for there, and move on... what about immediately
after the table?
-- 
Jim Nasby                                      [email-masked]
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

---

From: Tom Lane <[email-masked]>
Date: Sun, 13 May 2007 19:45:30 -0400

"Jim C. Nasby" <[email-masked]> writes:
>> Surely a section should not *begin* with a cross-reference to  
>> someplace else.

> what they're looking for there, and move on... what about immediately

Immediately after is fine with me.  For that matter, you could probably
get away with putting it between the introductory para and the table
proper.  I'm just allergic to sections that don't begin with a topic
sentence telling you what they are about.

			regards, tom lane

---

From: Jim Nasby <[email-masked]>
Date: Mon, 14 May 2007 13:47:18 -0500

> sentence telling you what they are about.

See attached. I wanted to not put it between the paragraph  
referencing the table and the table itself, but couldn't think of a  
better intro paragraph for the section...

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 30 May 2007 14:13:31 -0400 (EDT)

Patch applied.  Thanks.

---------------------------------------------------------------------------

> better intro paragraph for the section...
[ Attachment, skipping... ]

> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match