- 18 Jul, 2007 1 commit
-
-
Magnus Hagander authored
-
- 08 Jul, 2007 2 commits
-
-
Tom Lane authored
not OK to include postgres_fe.h into libpq-fe.h, hence declare it as returning int not bool.
-
Joe Conway authored
PGconn. Invent a new libpq connection-status function, PQconnectionUsedPassword() that returns true if the server demanded a password during authentication, false otherwise. This may be useful to clients in general, but is immediately useful to help plug a privilege escalation path in dblink. Per list discussion and design proposed by Tom Lane.
-
- 30 Mar, 2007 1 commit
-
-
Bruce Momjian authored
add link to libpq SSL does from server docs. Backpatch to 8.2.X.
-
- 20 Feb, 2007 2 commits
-
-
Bruce Momjian authored
-
Tom Lane authored
file permissions on Windows.
-
- 19 Feb, 2007 1 commit
-
-
Bruce Momjian authored
-
- 16 Feb, 2007 3 commits
-
-
Tom Lane authored
-
Bruce Momjian authored
detection of tabs are added in the future.
-
Bruce Momjian authored
o read global SSL configuration file o add GUC "ssl_ciphers" to control allowed ciphers o add libpq environment variable PGSSLKEY to control SSL hardware keys Victor B. Wagner
-
- 06 Feb, 2007 1 commit
-
-
Tom Lane authored
markup's broken. So just remove it...
-
- 05 Feb, 2007 1 commit
-
-
Bruce Momjian authored
-
- 04 Feb, 2007 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
Backpatch to 8.2.X.
-
- 01 Feb, 2007 1 commit
-
-
Bruce Momjian authored
appropriate.
-
- 31 Jan, 2007 1 commit
-
-
Bruce Momjian authored
Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash". Also update two error messages mentioned in the documenation to match.
-
- 30 Jan, 2007 1 commit
-
-
Bruce Momjian authored
more, and standard_conforming_strings less, because in the future non-E strings will not treat backslashes specially. Also use E'' strings where backslashes are used in examples. (The existing examples would have drawn warnings.) Backpatch to 8.2.X.
-
- 19 Dec, 2006 1 commit
-
-
Andrew Dunstan authored
Interpret a dbName param to PQsetdbLogin as a conninfo string if it contains an = sign. Tom Lane and Andrew Dunstan.
-
- 10 Nov, 2006 1 commit
-
-
Tom Lane authored
Theo Kramer.
-
- 23 Oct, 2006 1 commit
-
-
Peter Eisentraut authored
-
- 21 Oct, 2006 2 commits
-
-
Bruce Momjian authored
because the function didn't exist in 7.4.X.
-
Tom Lane authored
-
- 16 Sep, 2006 1 commit
-
-
Bruce Momjian authored
-
- 18 Aug, 2006 1 commit
-
-
Tom Lane authored
to allow obtaining information about previously prepared statements and open cursors. Volkan Yazici
-
- 27 Jul, 2006 1 commit
-
-
Bruce Momjian authored
Albe Laurenz
-
- 04 Jul, 2006 1 commit
-
-
Bruce Momjian authored
-
- 27 Jun, 2006 1 commit
-
-
Bruce Momjian authored
Christopher Kings-Lynne
-
- 23 May, 2006 1 commit
-
-
Bruce Momjian authored
the thread-safety status of the library.
-
- 21 May, 2006 1 commit
-
-
Tom Lane authored
and standard_conforming_strings. The encoding changes are needed for proper escaping in multibyte encodings, as per the SQL-injection vulnerabilities noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied to the server to ensure that it rejects queries that may have been corrupted by attempted SQL injection, but this merely guarantees that unpatched clients will fail rather than allow injection. An actual fix requires changing the client-side code. While at it we have also fixed these routines to understand about standard_conforming_strings, so that the upcoming changeover to SQL-spec string syntax can be somewhat transparent to client code. Since the existing API of PQescapeString and PQescapeBytea provides no way to inform them which settings are in use, these functions are now deprecated in favor of new functions PQescapeStringConn and PQescapeByteaConn. The new functions take the PGconn to which the string will be sent as an additional parameter, and look inside the connection structure to determine what to do. So as to provide some functionality for clients using the old functions, libpq stores the latest encoding and standard_conforming_strings values received from the backend in static variables, and the old functions consult these variables. This will work reliably in clients using only one Postgres connection at a time, or even multiple connections if they all use the same encoding and string syntax settings; which should cover many practical scenarios. Clients that use homebrew escaping methods, such as PHP's addslashes() function or even hardwired regexp substitution, will require extra effort to fix :-(. It is strongly recommended that such code be replaced by use of PQescapeStringConn/PQescapeByteaConn if at all feasible.
-
- 17 May, 2006 1 commit
-
-
Bruce Momjian authored
well as a blank pghost.
-
- 06 May, 2006 1 commit
-
-
Bruce Momjian authored
-
- 23 Apr, 2006 1 commit
-
-
Bruce Momjian authored
compatibility for release 7.2 and earlier. I have not altered any mentions of release 7.3 or later. The release notes were not modified, so the changes are still documented, just not in the main docs.
-
- 10 Mar, 2006 1 commit
-
-
Bruce Momjian authored
-
- 03 Mar, 2006 1 commit
-
-
Tom Lane authored
and tighten up its sanity checking of the tag as a safety measure. Volkan Yazici.
-
- 01 Mar, 2006 1 commit
-
-
Bruce Momjian authored
-
- 28 Feb, 2006 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 26 Dec, 2005 1 commit
-
-
Peter Eisentraut authored
-
- 23 Dec, 2005 1 commit
-
-
Tom Lane authored
modify the previous \password patch to use it instead of depending on a not-officially-exported function. Per discussion.
-
- 04 Nov, 2005 1 commit
-
-
Peter Eisentraut authored
-