Thread: PostgreSQL Password Cracker
Hi, Some guys from Turkey claim that they have a code to crack PostgreSQL passwords, defined in pg_hba.conf . http://www.core.gen.tr/pgcrack/ Maybe some of you want to get the code... Best regards, -- Devrim GUNDUZ www.gunduz.org
Devrim GUNDUZ <devrim@tr.net> writes: > Some guys from Turkey claim that they have a code to crack PostgreSQL > passwords, defined in pg_hba.conf . > http://www.core.gen.tr/pgcrack/ This is not a cracker, this is just a brute-force "try all possible passwords" search program (and a pretty simplistic one at that). I'd say all this proves is the importance of choosing a good password. Using only lowercase letters is a *bad* idea, especially if you're only going to use five of 'em... regards, tom lane
Hi, On Sal, 2002-12-31 at 19:38, Tom Lane wrote: > > This is not a cracker, this is just a brute-force "try all possible > passwords" search program (and a pretty simplistic one at that). Ah, you're right. > I'd say all this proves is the importance of choosing a good password. > Using only lowercase letters is a *bad* idea, especially if you're only > going to use five of 'em... I had no time to search throug the code; but as far as I understood, it *attacks* the database servers with TCP/IP on, right? Best regards, -- Devrim GUNDUZ www.gunduz.org devrim@tr.net
Tom Lane wrote: > Devrim GUNDUZ <devrim@tr.net> writes: > > Some guys from Turkey claim that they have a code to crack PostgreSQL > > passwords, defined in pg_hba.conf . > > > http://www.core.gen.tr/pgcrack/ > > This is not a cracker, this is just a brute-force "try all possible > passwords" search program (and a pretty simplistic one at that). > I'd say all this proves is the importance of choosing a good password. > Using only lowercase letters is a *bad* idea, especially if you're only > going to use five of 'em... Yea, that was my reaction too. Hard to see how we can guard against this. If they had used 8 lowercase characters, it would have been 36 days, if 8 upper and lower case, it would be 494 days, 8 upper/lowercase with numbers, 38284 days. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Devrim GUNDUZ wrote: > Hi, > > On Sal, 2002-12-31 at 19:38, Tom Lane wrote: > > > > This is not a cracker, this is just a brute-force "try all possible > > passwords" search program (and a pretty simplistic one at that). > > Ah, you're right. > > > I'd say all this proves is the importance of choosing a good password. > > Using only lowercase letters is a *bad* idea, especially if you're only > > going to use five of 'em... > > I had no time to search throug the code; but as far as I understood, it > *attacks* the database servers with TCP/IP on, right? It sniffs the packets going over the wire, so it can only be internet sockets, not unix domain sockets (both use tcp/ip). They basically sniff the text we send, and try passwords until the result matches the successful reply the client sent. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Devrim GUNDUZ <devrim@tr.net> writes:
> I had no time to search throug the code; but as far as I understood, it
> *attacks* the database servers with TCP/IP on, right?
No, the program itself simply takes an MD5 hash value and does a
brute-force search for a password that generates that MD5 string.
The comments at the top suggest sniffing a Postgres session startup
exchange in order to see the MD5 value that the user presents; which the
attacker would then give to this program. (Forget it if the session is
Unix-local rather than TCP, or if it's SSL-encrypted...)
This is certainly a theoretically possible attack against someone who
has no clue about security, but I don't put any stock in it as a
practical attack. For starters, if you are talking to your database
across a network that is open to hostile sniffers, you should definitely
be using SSL.
regards, tom lane
On Tue, 2002-12-31 at 17:49, Bruce Momjian wrote: > Tom Lane wrote: > > Devrim GUNDUZ <devrim@tr.net> writes: > > > Some guys from Turkey claim that they have a code to crack PostgreSQL > > > passwords, defined in pg_hba.conf . > > > > > http://www.core.gen.tr/pgcrack/ > > > > This is not a cracker, this is just a brute-force "try all possible > > passwords" search program (and a pretty simplistic one at that). > > I'd say all this proves is the importance of choosing a good password. > > Using only lowercase letters is a *bad* idea, especially if you're only > > going to use five of 'em... > > Yea, that was my reaction too. Hard to see how we can guard against > this. Keep a table of usernames used in connection attempts that failed because of a bad password. After 2 such failures, add 1 second sleep for each successive failure before responding to the next attempt for the same username. Max it at say 60 seconds. That should make brute force cracking unfeasible unless someone gets very lucky or the password is particularly weak. Zero the entry for a username as soon as there is a good connection. Is it worth doing? -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "Ye have heard that it hath been said, Thou shalt love thy neighbour, andhate thine enemy. But I say unto you, Love your enemies, bless them that curse you, do good to them that hateyou, and pray for them which despitefully use you, and persecute you;" Matthew 5:43,44
Oliver Elphick wrote: > On Tue, 2002-12-31 at 17:49, Bruce Momjian wrote: > > Tom Lane wrote: > > > Devrim GUNDUZ <devrim@tr.net> writes: > > > > Some guys from Turkey claim that they have a code to crack PostgreSQL > > > > passwords, defined in pg_hba.conf . > > > > > > > http://www.core.gen.tr/pgcrack/ > > > > > > This is not a cracker, this is just a brute-force "try all possible > > > passwords" search program (and a pretty simplistic one at that). > > > I'd say all this proves is the importance of choosing a good password. > > > Using only lowercase letters is a *bad* idea, especially if you're only > > > going to use five of 'em... > > > > Yea, that was my reaction too. Hard to see how we can guard against > > this. > > Keep a table of usernames used in connection attempts that failed > because of a bad password. After 2 such failures, add 1 second sleep > for each successive failure before responding to the next attempt for > the same username. Max it at say 60 seconds. That should make brute > force cracking unfeasible unless someone gets very lucky or the password > is particularly weak. The problem is that our MD5 algorithm is open source, so they are doing the checks in C looking for a match, not by sending the string to the server. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
<br /><br /> Tom Lane wrote:<br /><blockquote cite="mid1331.1041357853@sss.pgh.pa.us" type="cite"><pre wrap="">Devrim GUNDUZ<a class="moz-txt-link-rfc2396E" href="mailto:devrim@tr.net"><devrim@tr.net></a> writes: </pre><blockquote type="cite"><prewrap="">I had no time to search throug the code; but as far as I understood, it *attacks* the database servers with TCP/IP on, right? </pre></blockquote><pre wrap=""> No, the program itself simply takes an MD5 hash value and does a brute-force search for a password that generates that MD5 string. The comments at the top suggest sniffing a Postgres session startup exchange in order to see the MD5 value that the user presents; which the attacker would then give to this program. (Forget it if the session is Unix-local rather than TCP, or if it's SSL-encrypted...) This is certainly a theoretically possible attack against someone who has no clue about security, but I don't put any stock in it as a practical attack. For starters, if you are talking to your database across a network that is open to hostile sniffers, you should definitely be using SSL. </pre></blockquote> This is absolutely correct, shouldn't this be in the FAQ?<br /><blockquote cite="mid1331.1041357853@sss.pgh.pa.us"type="cite"><pre wrap=""> </pre></blockquote><br />
mlw wrote: > >The comments at the top suggest sniffing a Postgres session startup > >exchange in order to see the MD5 value that the user presents; which the > >attacker would then give to this program. (Forget it if the session is > >Unix-local rather than TCP, or if it's SSL-encrypted...) > > > >This is certainly a theoretically possible attack against someone who > >has no clue about security, but I don't put any stock in it as a > >practical attack. For starters, if you are talking to your database > >across a network that is open to hostile sniffers, you should definitely > >be using SSL. > > > > > This is absolutely correct, shouldn't this be in the FAQ? Well, this is a pretty rare issue, so it doesn't seem like an FAQ. People need to understand the ramifications of the various pg_hba.conf settings, and I think our documentation does that. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
<br /><br /> Bruce Momjian wrote:<br /><blockquote cite="mid200301012309.h01N9ZO28410@candle.pha.pa.us"
type="cite"><prewrap="">mlw wrote: </pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">The comments at
thetop suggest sniffing a Postgres session startup
exchange in order to see the MD5 value that the user presents; which the
attacker would then give to this program. (Forget it if the session is
Unix-local rather than TCP, or if it's SSL-encrypted...)
This is certainly a theoretically possible attack against someone who
has no clue about security, but I don't put any stock in it as a
practical attack. For starters, if you are talking to your database
across a network that is open to hostile sniffers, you should definitely
be using SSL.
</pre></blockquote><pre wrap="">This is absolutely correct, shouldn't this be in the FAQ?
</pre></blockquote><prewrap="">
Well, this is a pretty rare issue, so it doesn't seem like an FAQ.
People need to understand the ramifications of the various pg_hba.conf
settings, and I think our documentation does that. </pre></blockquote> A good DBA will probably read the docs, a bad
DBAwill probably not, and it is the bad DBA that needs to be guided the most.<br /><br /> Maybe not FAQ, but is the a
shortpage of "dos and don'ts?<br /><br /><br />
What do others think? I am not sure myself. --------------------------------------------------------------------------- mlw wrote: > > > Bruce Momjian wrote: > > >mlw wrote: > > > > > >>>The comments at the top suggest sniffing a Postgres session startup > >>>exchange in order to see the MD5 value that the user presents; which the > >>>attacker would then give to this program. (Forget it if the session is > >>>Unix-local rather than TCP, or if it's SSL-encrypted...) > >>> > >>>This is certainly a theoretically possible attack against someone who > >>>has no clue about security, but I don't put any stock in it as a > >>>practical attack. For starters, if you are talking to your database > >>>across a network that is open to hostile sniffers, you should definitely > >>>be using SSL. > >>> > >>> > >>> > >>> > >>This is absolutely correct, shouldn't this be in the FAQ? > >> > >> > > > >Well, this is a pretty rare issue, so it doesn't seem like an FAQ. > >People need to understand the ramifications of the various pg_hba.conf > >settings, and I think our documentation does that. > > > > > A good DBA will probably read the docs, a bad DBA will probably not, and > it is the bad DBA that needs to be guided the most. > > Maybe not FAQ, but is the a short page of "dos and don'ts? > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What do others think? I am not sure myself.
There should definitely be someplace that recommends using SSL across
insecure networks (if there's not already). But it doesn't seem to me
to qualify as a FAQ entry. Somewhere in the admin guide seems more
appropriate. Perhaps under Client Authentication?
Maybe someone could even put together enough material to create a whole
chapter on security considerations --- this is hardly the only item
worthy of mention.
regards, tom lane
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. Does anyone want to tackle this? --------------------------------------------------------------------------- Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > What do others think? I am not sure myself. > > There should definitely be someplace that recommends using SSL across > insecure networks (if there's not already). But it doesn't seem to me > to qualify as a FAQ entry. Somewhere in the admin guide seems more > appropriate. Perhaps under Client Authentication? > > Maybe someone could even put together enough material to create a whole > chapter on security considerations --- this is hardly the only item > worthy of mention. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
I'll do that. Justin: What's the URL for the .pgpass stuff? So far I see mention of using SSL. That's two items to cover. Anything else? On Wed, 1 Jan 2003, Bruce Momjian wrote: > > 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. > > Does anyone want to tackle this? > > --------------------------------------------------------------------------- > > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > What do others think? I am not sure myself. > > > > There should definitely be someplace that recommends using SSL across > > insecure networks (if there's not already). But it doesn't seem to me > > to qualify as a FAQ entry. Somewhere in the admin guide seems more > > appropriate. Perhaps under Client Authentication? > > > > Maybe someone could even put together enough material to create a whole > > chapter on security considerations --- this is hardly the only item > > worthy of mention. > > > > regards, tom lane > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (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 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html >
Dan Langille wrote: > I'll do that. Justin: What's the URL for the .pgpass stuff? So far I see > mention of using SSL. That's two items to cover. Anything else? Hi Dan, Very Cool. The URL for the .pgpass stuff is: http://developer.postgresql.org/docs/postgres/libpq-files.html :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On Fri, 3 Jan 2003, Justin Clift wrote: > Very Cool. The URL for the .pgpass stuff is: > > http://developer.postgresql.org/docs/postgres/libpq-files.html There is a typo on that page. First it talkes about the file .pgpass and then it says: "chmod 0600 .pgaccess". I had no idea that one could store the passwords like this. This feature is something I'm going to use from now on (now that I know about it). -- /Dennis
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. -- Peter Eisentraut peter_e@gmx.net
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
Dennis Bj�rklund wrote: > On Fri, 3 Jan 2003, Justin Clift wrote: > > > Very Cool. The URL for the .pgpass stuff is: > > > > http://developer.postgresql.org/docs/postgres/libpq-files.html > > There is a typo on that page. First it talkes about the file .pgpass and > then it says: "chmod 0600 .pgaccess". > > I had no idea that one could store the passwords like this. This feature > is something I'm going to use from now on (now that I know about it). I looked at CVS and the fix is in CVS head, but not in 7.3.X. I applied it only to CVS head because I wasn't sure if were were backpatching docs into CVS. I was later told we were rebuilding 7.3.X docs every night so we should backpatch docs. Also, does anyone know why the development docs are 7.3.1? http://developer.postgresql.org/docs/postgres/index.html Seems if it is on the developers page, it should be CVS head? Wasn't that supposed to build on demand? I don't think that is working. Perhaps it took too much CPU. The docs on my machine are based on CVS head and do build on demand: http://candle.pha.pa.us/main/writings/pgsql/sgml Both links are on the developers page. Is someone working to get 7.3.1 announced on our main web site? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: > 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. 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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Also, does anyone know why the development docs are 7.3.1?
Because it was pointed to that branch during the 7.3 beta cycle.
It needs to be repointed to CVS tip. I dunno how to do so, however.
> Is someone working to get 7.3.1 announced on our main web site?
I would like to think that someone in either the -advocacy or webmaster
groups will get around to that sometime soon ;-)
regards, tom lane
On Thu, 2003-01-02 at 19:33, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Also, does anyone know why the development docs are 7.3.1? > > Because it was pointed to that branch during the 7.3 beta cycle. > It needs to be repointed to CVS tip. I dunno how to do so, however. > > > Is someone working to get 7.3.1 announced on our main web site? > > I would like to think that someone in either the -advocacy or webmaster > groups will get around to that sometime soon ;-) > I don't want to speak for anyone else, but honestly I don't think anyone is working on it (I mean how long could it take to do it and how long has 7.3.1 been released?). I'd be happy to do it if someone would explain to me how to do it. I have a lot of access to a bunch of stuff but I don't think I have access to the cvs that the main site is stored in. Anonymous access and an email of who to send patches to would be enough if people are worried about me trashing things :-) Robert Treat
> -----Original Message----- > From: Robert Treat [mailto:xzilla@users.sourceforge.net] > Sent: 03 January 2003 15:36 > To: Tom Lane > Cc: Bruce Momjian; Justin Clift; > pgsql-hackers@postgresql.org; Dave Page > Subject: Re: [HACKERS] PostgreSQL Password Cracker > > > On Thu, 2003-01-02 at 19:33, Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > Also, does anyone know why the development docs are 7.3.1? > > > > Because it was pointed to that branch during the 7.3 beta cycle. It > > needs to be repointed to CVS tip. I dunno how to do so, however. > > > > > Is someone working to get 7.3.1 announced on our main web site? > > > > I would like to think that someone in either the -advocacy or > > webmaster groups will get around to that sometime soon ;-) > > > > I don't want to speak for anyone else, but honestly I don't > think anyone is working on it (I mean how long could it take > to do it and how long has 7.3.1 been released?). I'd be happy > to do it if someone would explain to me how to do it. I have > a lot of access to a bunch of stuff but I don't think I have > access to the cvs that the main site is stored in. Anonymous > access and an email of who to send patches to would be enough > if people are worried about me trashing things :-) www.postgresql.com - with a little luck should become www.postgresql.org rsn. Regards, Dave.
Tom Lane writes: > 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). The sections on environment variables and the .pgpass file are at the "sect1" level, which is about as prominent as I think we can make them. Certainly they are not a subject matter that warrants a whole chapter of their own. What's missing are some cross-references. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Tom Lane writes: > > > 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). > > The sections on environment variables and the .pgpass file are at the > "sect1" level, which is about as prominent as I think we can make them. > Certainly they are not a subject matter that warrants a whole chapter of > their own. What's missing are some cross-references. But it is a "sect1" in libpq. It should be a "sect1" somewhere that makes more sense. Right now it appears here:Table of Contents1. libpq - C Library 1.1. Introduction 1.2. Database Connection Functions 1.3. Command Execution Functions 1.4. Asynchronous Query Processing 1.5. The Fast-Path Interface 1.6.Asynchronous Notification 1.7. Functions Associated with the COPY Command 1.8. libpq Tracing Functions 1.9.libpq Control Functions 1.10. Environment Variables ^^^^^^^^^^^^^^^^^^^^^ 1.11. Files 1.12. ThreadingBehavior 1.13. Building Libpq Programs 1.14. Example Programs It doesn't belong in libpq, and it doesn't belong in the Programmer's Guide. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> But it is a "sect1" in libpq. It should be a "sect1" somewhere that
> makes more sense.
> ...
> It doesn't belong in libpq, and it doesn't belong in the Programmer's
> Guide.
How could it not belong in libpq? But you are right that the
Programmer's Guide seems the wrong place for information that is
important to end-users.
Perhaps libpq needs to have a chapter in the User's Guide as well as a
chapter in the Programmer's Guide? Or maybe we could put the relevant
information into a reference page under PostgreSQL Client Applications
(titled something along the line of "common behavior of all libpq-based
client applications").
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > But it is a "sect1" in libpq. It should be a "sect1" somewhere that > > makes more sense. > > ... > > It doesn't belong in libpq, and it doesn't belong in the Programmer's > > Guide. > > How could it not belong in libpq? But you are right that the > Programmer's Guide seems the wrong place for information that > is important to end-users. Some people don't even know libpq exists. If someone uses only psql, how would they know? > Perhaps libpq needs to have a chapter in the User's Guide as > well as a chapter in the Programmer's Guide? > Or maybe we could put the relevant information into a reference > page under PostgreSQL Client Applications (titled something > along the line of "common behavior of all libpq-based client > applications"). Yep, that's what I would do. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073