Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> 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.
Right. I think as a minimum, we need to move the libpq environment variables and, as Justin said, the .pgpass stuff out into its own section, and reference that from libpq and other interfaces/applications. We have had several reports of folks not knowing it, and it is obvious is it because the info is inside a C library API chapter. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
