Thread: System application reference pages
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? -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
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