System application reference pages

On Sun, 12 Nov 2000, Peter Eisentraut wrote:

The manual pages for initdb, initlocation, ipcclean, pg_passwd,
pg_upgrade, postgres, and postmaster should be moved to the
Administrator's Guide, because their usage is subject of the Admin Guide
and not of the User's Guide. Comments?

Makes sense to me *nod*

The Hermit Hacker wrote:

On Sun, 12 Nov 2000, Peter Eisentraut wrote:

The manual pages for initdb, initlocation, ipcclean, pg_passwd,
pg_upgrade, postgres, and postmaster should be moved to the
Administrator's Guide, because their usage is subject of the Admin Guide
and not of the User's Guide. Comments?

Makes sense to me *nod*

Yep. Makes lots of sense.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

The manual pages for initdb, initlocation, ipcclean, pg_passwd,
pg_upgrade, postgres, and postmaster should be moved to the
Administrator's Guide, because their usage is subject of the Admin Guide
and not of the User's Guide. Comments?

I'd originally put them all in the same place to make it easier to find
them (only one place to look) but division by purpose works too.

- Thomas

The manual pages for initdb, initlocation, ipcclean, pg_passwd,
pg_upgrade, postgres, and postmaster should be moved to the
Administrator's Guide, because their usage is subject of the Admin Guide
and not of the User's Guide. Comments?

Surely pg_ctl also belongs in that group.

One could make an argument that pg_dump, pg_dumpall, pg_restore, and
vacuumdb do too, though it'd be a weaker argument. Also createuser,
dropuser, perhaps createlang/droplang. All of these require superuser
privs to be more than marginally useful, so they strike me as primarily
admin tools not user tools.

regards, tom lane

Tom Lane writes:

One could make an argument that pg_dump, pg_dumpall, pg_restore, and
vacuumdb do too, though it'd be a weaker argument. Also createuser,
dropuser, perhaps createlang/droplang. All of these require superuser
privs to be more than marginally useful, so they strike me as primarily
admin tools not user tools.

If we did that, then it would only be logical to also move the associated
SQL commands, which might open a can of worms since one might also argue
for CREATE TYPE, CREATE FUNCTION, etc. in the programmer's guide, and at
the end we'll have them all over the place.

Perhaps it's time to revive the Reference Manual (reference.sgml) as an
extra, parallel document with only the reference pages.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Perhaps it's time to revive the Reference Manual (reference.sgml) as an
extra, parallel document with only the reference pages.

That would be fine (in my mind a better choice). *That* wasn't done
originally simply because the other part of the User's Guide was not
very big, but both pieces could now stand on their own.

- Thomas

I think in datatype.sgml line 506 or so:
<entry>varchar(n)</entry>
<entry>(4+x) bytes</entry>

should be
<entry>varchar(n)</entry>
<entry>(4+n) bytes</entry>

or
<entry>varchar(x)</entry>
<entry>(4+x) bytes</entry>

Regards

Laser

Thanks. Fix applied.

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

I think in datatype.sgml line 506 or so:
<entry>varchar(n)</entry>
<entry>(4+x) bytes</entry>

should be
<entry>varchar(n)</entry>
<entry>(4+n) bytes</entry>

or
<entry>varchar(x)</entry>
<entry>(4+x) bytes</entry>

Regards

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

I think in datatype.sgml line 506 or so...

Thanks Henry. Got it!

- Thomas