1. 28 8月, 2001 4 次提交
  2. 27 8月, 2001 9 次提交
  3. 26 8月, 2001 9 次提交
    • B
    • B
    • B
      >>>>The JDBC driver requires · 19a251d0
      Bruce Momjian 提交于
      >>>>
      >>>> permission java.net.SocketPermission "host:port", "connect";
      >>>>
      >>>>in the policy file of the application using the JDBC driver
      >>>>in the postgresql.jar file.  Since the Socket() call in the
      >>>>driver is not protected by AccessController.doPrivileged() this
      >>>>permission must also be granted to the entire application.
      >>>>
      >>>>The attached diff fixes it so that the connect permission can be
      >>>>restricted just the the postgresql.jar codeBase if desired.
      
      David Daney
      19a251d0
    • B
      Here is a patch to the resultmap to make the regression tests work on · 1be615f3
      Bruce Momjian 提交于
      OU8.
      
      Larry Rosenman
      1be615f3
    • B
      The attached file: SerializePatch2.tgz, contains a patch for · f4786925
      Bruce Momjian 提交于
      org.postgresql.util.Serialize and org.postgresql.jdbc2.PreparedStatement
      that  fixes the ability to "serialize" a simple java class into a
      postgres table.
      
      The current cvs seems completely broken in this support, so the patch
      puts it  into working condition, granted that there are many limitations
      with  serializing java classes into Postgres.
      
      The code to do serialize appears to have been in the driver since
      Postgres  6.4, according to some comments in the source.  My code is not
      adding any  totally new ability to the driver, rather just fixing what
      is there so that  it actually is usable.  I do not think that it should
      affect any existing  functions of the driver that people regularly
      depend on.
      
      The code is activated if you use jdbc2.PreparedStatement and try to
      setObject  some java class type that is unrecognized, like not String or
      not some other  primitive type.  This will cause a sequence of function
      calls that results in  an instance of Serialize being instantiated for
      the class type passed.  The  Serialize constructor will query pg_class
      to see if it can find an existing  table that matches the name of the
      java class. If found, it will continue and  try to use the table to
      store the object, otherwise an SQL exception is  thrown and no harm is
      done.  Serialize.create() has to be used to setup the  table for a java
      class before anything can really happen with this code other  than an
      SQLException (unless by some freak chance a table exists that it  thinks
      it can use).
      
      I saw a difference in Serialize.java between 7.1.3 and 7.2devel that I
      didn't  notice before, so I had to redo my changes from the 7.2devel
      version (why I  had to resend this patch now).  I was missing the
      fixString stuff, which is  nice and is imporant to ensure the inserts
      will not fail due to embedded  single quote or unescaped backslashes. I
      changed that fixString function in  Serialize just a little since there
      is no need to muddle with escaping  newlines: only escaping single quote
      and literal backslashes is needed.  Postgres appears to insert newlines
      within strings without trouble.
      f4786925
    • T
    • B
      a263e39b
    • T
      Replace implementation of pg_log as a relation accessed through the · 2589735d
      Tom Lane 提交于
      buffer manager with 'pg_clog', a specialized access method modeled
      on pg_xlog.  This simplifies startup (don't need to play games to
      open pg_log; among other things, OverrideTransactionSystem goes away),
      should improve performance a little, and opens the door to recycling
      commit log space by removing no-longer-needed segments of the commit
      log.  Actual recycling is not there yet, but I felt I should commit
      this part separately since it'd still be useful if we chose not to
      do transaction ID wraparound.
      2589735d
    • B
      4699d81d
  4. 25 8月, 2001 11 次提交
  5. 24 8月, 2001 2 次提交
  6. 23 8月, 2001 4 次提交
  7. 22 8月, 2001 1 次提交
    • B
      Attached is a simple one line patch for the problem reported in the · ef80c87f
      Bruce Momjian 提交于
      following email.
      
       > > The problem:  When I call getBigDecimal() on a ResultSet, it
       > > sometimes throws an exception:
       > >
       > >   Bad BigDecimal 174.50
       > >     at org.postgresql.jdbc2.ResultSet.getBigDecimal(ResultSet.java:373)
       > >     at org.postgresql.jdbc2.ResultSet.getBigDecimal(ResultSet.java:984)
       > >     ...blah blah blah...
       > >   org.postgresql.util.PSQLException: Bad BigDecimal 174.50
      
      Barry Lind
      ef80c87f