I was thinking of something similar to our encryption section:


The idea being to define issues like multi/single master, async vs,
sync, and mention the projects which are in each category.


Peter Eisentraut wrote:
> Alvaro Herrera wrote:
> > > >I don't think this sort of material belongs directly into the
> > > > PostgreSQL documentation.
> >
> > Why not?
> PostgreSQL documentation (or any product documentation) should be 
> factual: describe what the software does and give advice on its use.  
> This should be mostly independent of the external circumstances, 
> because people will still read that documentation three or four years 
> from now.
> The proposed text is, at least partially, journalistic: it evaluates 
> competing ideas, gives historical and anecdotal information, reports on 
> current events, and makes speculations about the future.  That is the 
> sort of material that is published in periodicals or other volatile 
> media.
> At the summit, we resolved, for precisely these reasons, to keep the 
> journalistic parts on the web site, for clear separation from the 
> shipped product and for easier updates (and for easier reference as 
> well, because the PostgreSQL documentation is not the single obvious 
> place to look for it) and refer to it from the documentation.
> -- 
> Peter Eisentraut
> http://developer.postgresql.org/~petere/
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>                http://archives.postgresql.org

  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDB    http://www.enterprisedb.com

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to