[DOCS] documenting contrib modules (was Re: Building PDFs error)

2011-03-14 Thread Robert Haas 
On Sat, Mar 12, 2011 at 3:57 PM, Tom Lane  wrote:
> Peter Eisentraut  writes:
>> On lör, 2011-03-12 at 09:13 -0500, Bruce Momjian wrote:
>>> OK, it is not something worthwhile, or just something you don't have
>>> time for.  If the later, can you give us a hint on how to fix it?
>
>> I'm not even sure what the actual action item is supposed to be.
>
> The last suggestion in the thread was to move the contrib docs up one
> level in the hierarchy, ie each contrib module would get a chapter not a
> sect1.

Trouble is, many of those will be extremely short chapters.  Consider
passwordcheck, for example.

I think that contrib has a bit of a split-personality disorder at
present.  It has at least four different kinds of things in it:

- First-class citizens intended to provide core functionality
(file_fdw, pg_upgrade, dblink, hstore, sepgsql, pg_archivecleanup)
- Debugging and instrumentation tools (pageinspect, pg_buffercache,
pg_rowlocks, pg_stat_statements, auto_explain, oid2name)
- Code examples, some of which are also used for regression testing
(spi, dummy_seclabel, test_parser)
- Modules that are largely superseded by new core features, but we
can't quite bring ourselves to kill them yet because they still have
some possible remaining utility (xml2, intarray, intagg)

I think it would be really helpful to try to group these modules in
some way, and perhaps provide a chapter for each group rather than a
chapter for the entire set.  If you're looking at contrib for the
first time, it's pretty hard to know that the thing called hstore is
something many people think is teh awesome while the thing called
intagg is a compatibility wrapper with no obvious residual utility
whatsoever.  Arguably we should try to rearrange the actual source
code tree at some point, too, but maybe that should left for phase 2.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] Multi-language glossary of PostgreSQL terms.

2011-03-14 Thread Euler Taveira de Oliveira 

Em 13-03-2011 15:44, Dmitriy Igrishin escreveu:

First of all, we want to create glossary to be used by translators.
However we consider that it would be nice to generalize this idea
and create a multi-language glossary of PostgreSQL terms on
wiki.postgresql.org .

Nice. We already have a glossary [1] for brazilian portuguese. It is used to 
PostgreSQL related translations (including gettext messages and documentation).


I'm not sure if multi-language glossary is a way to go. There are 
terms/expressions that have more than one translation depending on context. 
But in some languages, they have just one translation. So the brazilian 
portuguese glossary would be different from russian and japanese glossary.



[1] http://www.timbira.com/pg/vp.txt


--
  Euler Taveira de Oliveira
  http://www.timbira.com/

--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] Multi-language glossary of PostgreSQL terms.

2011-03-14 Thread Dmitriy Igrishin 
Hey Pavel, Euler

Thanks for you answers!

2011/3/14 Euler Taveira de Oliveira 

> Em 13-03-2011 15:44, Dmitriy Igrishin escreveu:
>
>> First of all, we want to create glossary to be used by translators.
>> However we consider that it would be nice to generalize this idea
>> and create a multi-language glossary of PostgreSQL terms on
>> wiki.postgresql.org .
>>
>>  Nice. We already have a glossary [1] for brazilian portuguese. It is used
> to PostgreSQL related translations (including gettext messages and
> documentation).
>
> I'm not sure if multi-language glossary is a way to go. There are
> terms/expressions that have more than one translation depending on context.
> But in some languages, they have just one translation. So the brazilian
> portuguese glossary would be different from russian and japanese glossary.
>
There is nothing impossible. :-)
I'm sure it's possible to maintain multi-language glossary of
common phrases which are treated unequivocally.
Furthermore, nothing prevents to create specialized (or extended)
glossary for some language (e.g. for mentioned cases when
one term's translation depends on context). So, we can create
and maintain the hierarchy of glossaries with a common root
and its specializations !


>
> [1] http://www.timbira.com/pg/vp.txt
>
>
> --
>  Euler Taveira de Oliveira
>  http://www.timbira.com/
>



-- 
// Dmitriy.

[DOCS] Help

2011-03-14 Thread rikard wallen 
How do I find the information about my postgresql such as: server, database
user, port, password
thank you

Re: [DOCS] Help

2011-03-14 Thread Andrej 
On 15 March 2011 07:57, rikard wallen  wrote:
> How do I find the information about my postgresql such as: server, database
> user, port, password
> thank you

Most commonly that will be
server = the machine you installed postgres on
port= postgres' default 5432 unless you changed it on installation
user   = the user account that owns the database in question
password = the password you assigned to that user



Cheers,
Andrej

-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs