Re: PostgreSQL Password Cracker - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PostgreSQL Password Cracker
Date
Msg-id 5020.1041549633@sss.pgh.pa.us
Whole thread Raw
In response to Re: PostgreSQL Password Cracker  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: PostgreSQL Password Cracker  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: PostgreSQL Password Cracker  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Bruce Momjian writes:
>> Yes, I have been feeling we should do that.  Justin pointed out just
>> yesterday that .pgpass is only mentioned in libpq documentation, and in
>> fact there is lots of stuff mentioned in libpq that releates to the
>> other interfaces, so it should be pulled out and put in one place.

> It is difficult to make out which place that would be.  You can duplicate
> the information in every place where an interface or tool that uses libpq
> is documented, but that doesn't seem to be conceptually superior.

Duplicating this info is clearly a losing proposition.  But I think
Bruce is envisioning restructuring the documentation of libpq to
separate out the parts that are only interesting to a programmer using
libpq from the parts that are interesting to a user of a libpq-based
program (for example, all the info about environment variables, conninfo
string syntax, and .pgpass).  Then the docs for interfaces and tools
could cross-reference the "externally visible behavior" section of the
libpq docs --- and this section would make sense to an end user,
without drowning him in details he doesn't care about.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Upgrading rant.
Next
From: Bruce Momjian
Date:
Subject: Re: PostgreSQL Password Cracker