pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedminor documentation improvements
12+ messages / 4 participants
[nested] [flat]
* minor documentation improvements
@ 2003-09-05 00:21 Neil Conway <neilc@samurai.com>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
2003-09-11 17:31 ` Re: minor documentation improvements Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 2 replies; 12+ messages in thread
From: Neil Conway @ 2003-09-05 00:21 UTC (permalink / raw)
To: PostgreSQL Patches <pgsql-patches@postgresql.org>
This patch makes a few minor improvements to the docs: make the
<varname> conventions more consistent, and improve the ANALYZE ref page.
-Neil
Attachments:
misc-doc-improvements-1.patch (text/x-patch, 12.4K) download
Index: doc/src/sgml/perform.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/perform.sgml,v
retrieving revision 1.31
diff -c -r1.31 perform.sgml
*** doc/src/sgml/perform.sgml 31 Aug 2003 17:32:19 -0000 1.31
--- doc/src/sgml/perform.sgml 5 Sep 2003 00:15:21 -0000
***************
*** 603,609 ****
<productname>PostgreSQL</productname> planner will switch from exhaustive
search to a <firstterm>genetic</firstterm> probabilistic search
through a limited number of possibilities. (The switch-over threshold is
! set by the <varname>geqo_threshold</varname> run-time
parameter.)
The genetic search takes less time, but it won't
necessarily find the best possible plan.
--- 603,609 ----
<productname>PostgreSQL</productname> planner will switch from exhaustive
search to a <firstterm>genetic</firstterm> probabilistic search
through a limited number of possibilities. (The switch-over threshold is
! set by the <varname>GEQO_THRESHOLD</varname> run-time
parameter.)
The genetic search takes less time, but it won't
necessarily find the best possible plan.
Index: doc/src/sgml/plpgsql.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/plpgsql.sgml,v
retrieving revision 1.22
diff -c -r1.22 plpgsql.sgml
*** doc/src/sgml/plpgsql.sgml 3 Sep 2003 22:17:07 -0000 1.22
--- doc/src/sgml/plpgsql.sgml 5 Sep 2003 00:11:49 -0000
***************
*** 1350,1356 ****
allow users to allow users to define set-returning functions
that do not have this limitation. Currently, the point at
which data begins being written to disk is controlled by the
! <varname>sort_mem</> configuration variable. Administrators
who have sufficient memory to store larger result sets in
memory should consider increasing this parameter.
</para>
--- 1350,1356 ----
allow users to allow users to define set-returning functions
that do not have this limitation. Currently, the point at
which data begins being written to disk is controlled by the
! <varname>SORT_MEM</> configuration variable. Administrators
who have sufficient memory to store larger result sets in
memory should consider increasing this parameter.
</para>
Index: doc/src/sgml/ref/analyze.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/analyze.sgml,v
retrieving revision 1.13
diff -c -r1.13 analyze.sgml
*** doc/src/sgml/ref/analyze.sgml 31 Aug 2003 17:32:21 -0000 1.13
--- doc/src/sgml/ref/analyze.sgml 5 Sep 2003 00:02:12 -0000
***************
*** 28,37 ****
<title>Description</title>
<para>
! <command>ANALYZE</command> collects statistics about the contents of
! tables in the database, and stores the results in
! the system table <literal>pg_statistic</literal>. Subsequently,
! the query planner uses the statistics to help determine the most efficient
execution plans for queries.
</para>
--- 28,37 ----
<title>Description</title>
<para>
! <command>ANALYZE</command> collects statistics about the contents
! of tables in the database, and stores the results in the system
! table <literal>pg_statistic</literal>. Subsequently, the query
! planner uses these statistics to help determine the most efficient
execution plans for queries.
</para>
***************
*** 105,153 ****
</para>
<para>
! Unlike <command>VACUUM FULL</command>,
! <command>ANALYZE</command> requires
! only a read lock on the target table, so it can run in parallel with
! other activity on the table.
</para>
<para>
! For large tables, <command>ANALYZE</command> takes a random sample of the
! table contents, rather than examining every row. This allows even very
! large tables to be analyzed in a small amount of time. Note, however,
! that the statistics are only approximate, and will change slightly each
! time <command>ANALYZE</command> is run, even if the actual table contents
! did not change. This may result in small changes in the planner's
! estimated costs shown by <command>EXPLAIN</command>.
</para>
<para>
! The collected statistics usually include a list of some of the most common
! values in each column and a histogram showing the approximate data
! distribution in each column. One or both of these may be omitted if
! <command>ANALYZE</command> deems them uninteresting (for example, in
! a unique-key column, there are no common values) or if the column
! data type does not support the appropriate operators. There is more
! information about the statistics in <xref linkend="maintenance">.
</para>
<para>
The extent of analysis can be controlled by adjusting the
! <literal>default_statistics_target</> parameter variable, or on a
! column-by-column basis by setting the per-column
! statistics target with <command>ALTER TABLE ... ALTER COLUMN ... SET
! STATISTICS</command> (see
! <xref linkend="sql-altertable" endterm="sql-altertable-title">). The
! target value sets the maximum number of entries in the most-common-value
! list and the maximum number of bins in the histogram. The default
! target value is 10, but this can be adjusted up or down to trade off
! accuracy of planner estimates against the time taken for
! <command>ANALYZE</command> and the amount of space occupied
! in <literal>pg_statistic</literal>.
! In particular, setting the statistics target to zero disables collection of
! statistics for that column. It may be useful to do that for columns that
! are never used as part of the <literal>WHERE</>, <literal>GROUP BY</>, or <literal>ORDER BY</> clauses of
! queries, since the planner will have no use for statistics on such columns.
</para>
<para>
--- 105,160 ----
</para>
<para>
! Unlike <command>VACUUM FULL</command>, <command>ANALYZE</command>
! requires only a read lock on the target table, so it can run in
! parallel with other activity on the table.
</para>
<para>
! The statistics collected by <command>ANALYZE</command> usually
! include a list of some of the most common values in each column and
! a histogram showing the approximate data distribution in each
! column. One or both of these may be omitted if
! <command>ANALYZE</command> deems them uninteresting (for example,
! in a unique-key column, there are no common values) or if the
! column data type does not support the appropriate operators. There
! is more information about the statistics in <xref
! linkend="maintenance">.
</para>
<para>
! For large tables, <command>ANALYZE</command> takes a random sample
! of the table contents, rather than examining every row. This
! allows even very large tables to be analyzed in a small amount of
! time. Note, however, that the statistics are only approximate, and
! will change slightly each time <command>ANALYZE</command> is run,
! even if the actual table contents did not change. This may result
! in small changes in the planner's estimated costs shown by
! <command>EXPLAIN</command>. In rare situations, this
! non-determinism will cause the query optimizer to choose a
! different query plan between runs of <command>ANALYZE</command>. To
! avoid this, raise the amount of statistics collected by
! <command>ANALYZE</command>, as described below.
</para>
<para>
The extent of analysis can be controlled by adjusting the
! <varname>DEFAULT_STATISTICS_TARGET</varname> parameter variable, or
! on a column-by-column basis by setting the per-column statistics
! target with <command>ALTER TABLE ... ALTER COLUMN ... SET
! STATISTICS</command> (see <xref linkend="sql-altertable"
! endterm="sql-altertable-title">). The target value sets the
! maximum number of entries in the most-common-value list and the
! maximum number of bins in the histogram. The default target value
! is 10, but this can be adjusted up or down to trade off accuracy of
! planner estimates against the time taken for
! <command>ANALYZE</command> and the amount of space occupied in
! <literal>pg_statistic</literal>. In particular, setting the
! statistics target to zero disables collection of statistics for
! that column. It may be useful to do that for columns that are
! never used as part of the <literal>WHERE</>, <literal>GROUP BY</>,
! or <literal>ORDER BY</> clauses of queries, since the planner will
! have no use for statistics on such columns.
</para>
<para>
Index: doc/src/sgml/ref/create_user.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/create_user.sgml,v
retrieving revision 1.27
diff -c -r1.27 create_user.sgml
*** doc/src/sgml/ref/create_user.sgml 31 Aug 2003 17:32:22 -0000 1.27
--- doc/src/sgml/ref/create_user.sgml 5 Sep 2003 00:08:59 -0000
***************
*** 98,104 ****
These key words control whether the password is stored
encrypted in the system catalogs. (If neither is specified,
the default behavior is determined by the configuration
! parameter <varname>password_encryption</varname>.) If the
presented password string is already in MD5-encrypted format,
then it is stored encrypted as-is, regardless of whether
<literal>ENCRYPTED</> or <literal>UNENCRYPTED</> is specified
--- 98,104 ----
These key words control whether the password is stored
encrypted in the system catalogs. (If neither is specified,
the default behavior is determined by the configuration
! parameter <varname>PASSWORD_ENCRYPTION</varname>.) If the
presented password string is already in MD5-encrypted format,
then it is stored encrypted as-is, regardless of whether
<literal>ENCRYPTED</> or <literal>UNENCRYPTED</> is specified
Index: doc/src/sgml/ref/postmaster.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/postmaster.sgml,v
retrieving revision 1.37
diff -c -r1.37 postmaster.sgml
*** doc/src/sgml/ref/postmaster.sgml 31 Aug 2003 17:32:24 -0000 1.37
--- doc/src/sgml/ref/postmaster.sgml 5 Sep 2003 00:12:50 -0000
***************
*** 376,382 ****
<listitem>
<para>
! Default value of the <literal>datestyle</literal> run-time
parameter. (The use of this environment variable is deprecated.)
</para>
</listitem>
--- 376,382 ----
<listitem>
<para>
! Default value of the <varname>DATESTYLE</varname> run-time
parameter. (The use of this environment variable is deprecated.)
</para>
</listitem>
***************
*** 563,569 ****
<prompt>$</prompt> <userinput>postmaster -c sort_mem=1234</userinput>
<prompt>$</prompt> <userinput>postmaster --sort-mem=1234</userinput>
</screen>
! Either form overrides whatever setting might exist for <literal>sort_mem</>
in <filename>postgresql.conf</>. Notice that underscores in parameter
names can be written as either underscore or dash on the command line.
</para>
--- 563,569 ----
<prompt>$</prompt> <userinput>postmaster -c sort_mem=1234</userinput>
<prompt>$</prompt> <userinput>postmaster --sort-mem=1234</userinput>
</screen>
! Either form overrides whatever setting might exist for <varname>SORT_MEM</>
in <filename>postgresql.conf</>. Notice that underscores in parameter
names can be written as either underscore or dash on the command line.
</para>
Index: doc/src/sgml/ref/reset.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/reset.sgml,v
retrieving revision 1.21
diff -c -r1.21 reset.sgml
*** doc/src/sgml/ref/reset.sgml 31 Aug 2003 17:32:24 -0000 1.21
--- doc/src/sgml/ref/reset.sgml 5 Sep 2003 00:16:07 -0000
***************
*** 93,106 ****
<title>Examples</title>
<para>
! Set <varname>datestyle</> to its default value:
<screen>
RESET datestyle;
</screen>
</para>
<para>
! Set <varname>geqo</> to its default value:
<screen>
RESET geqo;
</screen>
--- 93,106 ----
<title>Examples</title>
<para>
! Set <varname>DATESTYLE</> to its default value:
<screen>
RESET datestyle;
</screen>
</para>
<para>
! Set <varname>GEQO</> to its default value:
<screen>
RESET geqo;
</screen>
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <neilc@samurai.com>
@ 2003-09-05 20:39 ` Peter Eisentraut <peter_e@gmx.net>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-05 23:29 ` Re: minor documentation improvements Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 2 replies; 12+ messages in thread
From: Peter Eisentraut @ 2003-09-05 20:39 UTC (permalink / raw)
To: Neil Conway <neilc@samurai.com>; +Cc: PostgreSQL Patches <pgsql-patches@postgresql.org>
Neil Conway writes:
> This patch makes a few minor improvements to the docs: make the
> <varname> conventions more consistent,
They are consistent: They're all lowercase. Until now.
--
Peter Eisentraut peter_e@gmx.net
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <neilc@samurai.com>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
@ 2003-09-05 20:58 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-05 21:16 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
1 sibling, 1 reply; 12+ messages in thread
From: Bruce Momjian @ 2003-09-05 20:58 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: Neil Conway <neilc@samurai.com>; PostgreSQL Patches <pgsql-patches@postgresql.org>
Peter Eisentraut wrote:
> Neil Conway writes:
>
> > This patch makes a few minor improvements to the docs: make the
> > <varname> conventions more consistent,
>
> They are consistent: They're all lowercase. Until now.
Huh? We have been uppercasing GUC variable names in most places
already.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <neilc@samurai.com>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <pgman@candle.pha.pa.us>
@ 2003-09-05 21:16 ` Peter Eisentraut <peter_e@gmx.net>
2003-09-05 21:18 ` Re: minor documentation improvements Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-05 23:24 ` Re: minor documentation improvements Neil Conway <neilc@samurai.com>
2003-09-05 23:35 ` Re: minor documentation improvements Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 3 replies; 12+ messages in thread
From: Peter Eisentraut @ 2003-09-05 21:16 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Neil Conway <neilc@samurai.com>; PostgreSQL Patches <pgsql-patches@postgresql.org>
Bruce Momjian writes:
> Huh? We have been uppercasing GUC variable names in most places
> already.
Currently, the documentation contains about 2 GUC variable names in upper
case, the rest is lower case. (The exception are the list headings in the
main description in runtime.sgml, which are all upper case. That is a bit
inconsistent, but I think it's OK, because here they sort of serve as
section titles.) Also note that postgresql.conf, command-line option
equivalents, and SET commands all tend to use them in lower case, so that
seems like the direction to go.
--
Peter Eisentraut peter_e@gmx.net
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <neilc@samurai.com>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-05 21:16 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
@ 2003-09-05 21:18 ` Bruce Momjian <pgman@candle.pha.pa.us>
2 siblings, 0 replies; 12+ messages in thread
From: Bruce Momjian @ 2003-09-05 21:18 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: Neil Conway <neilc@samurai.com>; PostgreSQL Patches <pgsql-patches@postgresql.org>
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Huh? We have been uppercasing GUC variable names in most places
> > already.
>
> Currently, the documentation contains about 2 GUC variable names in upper
> case, the rest is lower case. (The exception are the list headings in the
> main description in runtime.sgml, which are all upper case. That is a bit
> inconsistent, but I think it's OK, because here they sort of serve as
> section titles.) Also note that postgresql.conf, command-line option
> equivalents, and SET commands all tend to use them in lower case, so that
> seems like the direction to go.
Oh, OK, got it.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <neilc@samurai.com>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-05 21:16 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
@ 2003-09-05 23:24 ` Neil Conway <neilc@samurai.com>
2003-09-06 11:29 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
2 siblings, 1 reply; 12+ messages in thread
From: Neil Conway @ 2003-09-05 23:24 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; PostgreSQL Patches <pgsql-patches@postgresql.org>
On Fri, 2003-09-05 at 17:16, Peter Eisentraut wrote:
> Currently, the documentation contains about 2 GUC variable names in upper
> case, the rest is lower case.
There are significantly more than 2 uses of upper-case GUC names in the
docs (more like 10 by my guess), but in any case, the current usage is
inconsistent.
So, is upper-case or lower-case better? I'd personally prefer
lower-case, I suppose, but I'm not too bothered either way.
-Neil
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <neilc@samurai.com>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-05 21:16 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
2003-09-05 23:24 ` Re: minor documentation improvements Neil Conway <neilc@samurai.com>
@ 2003-09-06 11:29 ` Peter Eisentraut <peter_e@gmx.net>
2003-09-10 20:05 ` Re: [PATCHES] minor documentation improvements Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 12+ messages in thread
From: Peter Eisentraut @ 2003-09-06 11:29 UTC (permalink / raw)
To: Neil Conway <neilc@samurai.com>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; PostgreSQL Patches <pgsql-patches@postgresql.org>
Neil Conway writes:
> So, is upper-case or lower-case better? I'd personally prefer
> lower-case, I suppose, but I'm not too bothered either way.
If you want to change them all to lowercase, that would be fine by me. At
least it would prevent more people being confused into inconsistencies in
the future.
--
Peter Eisentraut peter_e@gmx.net
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [PATCHES] minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <neilc@samurai.com>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-05 21:16 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
2003-09-05 23:24 ` Re: minor documentation improvements Neil Conway <neilc@samurai.com>
2003-09-06 11:29 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
@ 2003-09-10 20:05 ` Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 0 replies; 12+ messages in thread
From: Bruce Momjian @ 2003-09-10 20:05 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: Neil Conway <neilc@samurai.com>; pgsql-docs
Peter Eisentraut wrote:
> Neil Conway writes:
>
> > So, is upper-case or lower-case better? I'd personally prefer
> > lower-case, I suppose, but I'm not too bothered either way.
>
> If you want to change them all to lowercase, that would be fine by me. At
> least it would prevent more people being confused into inconsistencies in
> the future.
Have we come to a conclusion here --- that we should lowercase _all_ GUC
variable references, both in runtime.sgml, SGML docs, and error
messages?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <neilc@samurai.com>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-05 21:16 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
@ 2003-09-05 23:35 ` Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 12+ messages in thread
From: Tom Lane @ 2003-09-05 23:35 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; Neil Conway <neilc@samurai.com>; PostgreSQL Patches <pgsql-patches@postgresql.org>
Peter Eisentraut <peter_e@gmx.net> writes:
> Bruce Momjian writes:
>> Huh? We have been uppercasing GUC variable names in most places
>> already.
> Currently, the documentation contains about 2 GUC variable names in upper
> case, the rest is lower case. (The exception are the list headings in the
> main description in runtime.sgml, which are all upper case. That is a bit
> inconsistent, but I think it's OK, because here they sort of serve as
> section titles.)
Okay, that seems reasonable. Ignore my prior message --- I hadn't come
across this one yet.
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <neilc@samurai.com>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <peter_e@gmx.net>
@ 2003-09-05 23:29 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 12+ messages in thread
From: Tom Lane @ 2003-09-05 23:29 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: Neil Conway <neilc@samurai.com>; PostgreSQL Patches <pgsql-patches@postgresql.org>
Peter Eisentraut <peter_e@gmx.net> writes:
> Neil Conway writes:
>> This patch makes a few minor improvements to the docs: make the
>> <varname> conventions more consistent,
> They are consistent: They're all lowercase. Until now.
The varnames listed in runtime.sgml are uppercase though, no? Or were
you intending the variable definitions to be upper case and all the
references lower case? It's not real clear what the intended style is,
and I have to say that I thought Neil was heading in the intended
direction also.
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <neilc@samurai.com>
@ 2003-09-11 17:31 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-11 18:29 ` Re: minor documentation improvements Bruce Momjian <pgman@candle.pha.pa.us>
1 sibling, 1 reply; 12+ messages in thread
From: Bruce Momjian @ 2003-09-11 17:31 UTC (permalink / raw)
To: Neil Conway <neilc@samurai.com>; +Cc: PostgreSQL Patches <pgsql-patches@postgresql.org>
Patch applied. I will now go through and lowercase all the GUC
variable names, as agreed upon.
---------------------------------------------------------------------------
Neil Conway wrote:
> This patch makes a few minor improvements to the docs: make the
> <varname> conventions more consistent, and improve the ANALYZE ref page.
>
> -Neil
>
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <neilc@samurai.com>
2003-09-11 17:31 ` Re: minor documentation improvements Bruce Momjian <pgman@candle.pha.pa.us>
@ 2003-09-11 18:29 ` Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 0 replies; 12+ messages in thread
From: Bruce Momjian @ 2003-09-11 18:29 UTC (permalink / raw)
To: PostgreSQL-patches <pgsql-patches@postgresql.org>; +Cc: Neil Conway <neilc@samurai.com>
Patch attached and applied.
---------------------------------------------------------------------------
Bruce Momjian wrote:
>
> Patch applied. I will now go through and lowercase all the GUC
> variable names, as agreed upon.
>
> ---------------------------------------------------------------------------
>
> Neil Conway wrote:
> > This patch makes a few minor improvements to the docs: make the
> > <varname> conventions more consistent, and improve the ANALYZE ref page.
> >
> > -Neil
> >
>
> [ Attachment, skipping... ]
>
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Attachments:
/bjm/diff (text/plain, 80.2K) download
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2003-09-11 18:29 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-09-05 00:21 minor documentation improvements Neil Conway <neilc@samurai.com>
2003-09-05 20:39 ` Peter Eisentraut <peter_e@gmx.net>
2003-09-05 20:58 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-05 21:16 ` Peter Eisentraut <peter_e@gmx.net>
2003-09-05 21:18 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-05 23:24 ` Neil Conway <neilc@samurai.com>
2003-09-06 11:29 ` Peter Eisentraut <peter_e@gmx.net>
2003-09-10 20:05 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-05 23:35 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-09-05 23:29 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-09-11 17:31 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-11 18:29 ` Bruce Momjian <pgman@candle.pha.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox