1. 18 Jul, 2007 1 commit
  2. 08 Jul, 2007 2 commits
  3. 30 Mar, 2007 1 commit
  4. 20 Feb, 2007 2 commits
  5. 19 Feb, 2007 1 commit
  6. 16 Feb, 2007 3 commits
  7. 06 Feb, 2007 1 commit
  8. 05 Feb, 2007 1 commit
  9. 04 Feb, 2007 2 commits
  10. 01 Feb, 2007 1 commit
  11. 31 Jan, 2007 1 commit
    • Bruce Momjian's avatar
      Update documentation on may/can/might: · a134ee33
      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.
      a134ee33
  12. 30 Jan, 2007 1 commit
  13. 19 Dec, 2006 1 commit
  14. 10 Nov, 2006 1 commit
  15. 23 Oct, 2006 1 commit
  16. 21 Oct, 2006 2 commits
  17. 16 Sep, 2006 1 commit
  18. 18 Aug, 2006 1 commit
  19. 27 Jul, 2006 1 commit
  20. 04 Jul, 2006 1 commit
  21. 27 Jun, 2006 1 commit
  22. 23 May, 2006 1 commit
  23. 21 May, 2006 1 commit
    • Tom Lane's avatar
      Modify libpq's string-escaping routines to be aware of encoding considerations · 515112f9
      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.
      515112f9
  24. 17 May, 2006 1 commit
  25. 06 May, 2006 1 commit
  26. 23 Apr, 2006 1 commit
  27. 10 Mar, 2006 1 commit
  28. 03 Mar, 2006 1 commit
  29. 01 Mar, 2006 1 commit
  30. 28 Feb, 2006 2 commits
  31. 26 Dec, 2005 1 commit
  32. 23 Dec, 2005 1 commit
  33. 04 Nov, 2005 1 commit