Skip to content
Snippets Groups Projects
  1. May 04, 2003
    • Tom Lane's avatar
      When a TIMESTAMP, TIME, or INTERVAL precision is specified larger than our · ac5fdea6
      Tom Lane authored
      implementation limits, do not issue an ERROR; instead issue a NOTICE and use
      the max supported value.  Per pgsql-general discussion of 28-Apr, this is
      needed to allow easy porting from pre-7.3 releases where the limits were
      higher.
      
      Unrelated change in same area: accept GLOBAL TEMP/TEMPORARY as a synonym
      for TEMPORARY, as per pgsql-hackers discussion of 15-Apr.  We previously
      rejected it, but that was based on a misreading of the spec --- SQL92's
      GLOBAL temp tables are really closer to what we have than their LOCAL ones.
      ac5fdea6
    • Tom Lane's avatar
      Fix erroneous space calculation leading to core dump in dumpProcLangs, · 22869717
      Tom Lane authored
      per report from Olivier Prenant.  Also fix off-by-one space calculation
      in ReadToc; this woould not have hurt us until we had more than 100
      dependencies for a single object, but wrong is wrong.
      22869717
  2. May 03, 2003
    • Barry Lind's avatar
      Patch to fix up LONGVARBINARY support submitted by Amit Gollapudi · 5295fffc
      Barry Lind authored
      (agollapudi@demandsolutions.com).
      Also applied the RefCursor support patch by Nic Ferrier.  This patch allows
      you too return a get a result set from a function that returns a refcursor.
      For example:
      call.registerOutParameter(1, Types.OTHER);
      call.execute();
      ResultSet rs = (ResultSet) call.getObject(1);
      
      Modified Files:
       	jdbc/org/postgresql/core/BaseStatement.java
       	jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
       	jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
       	jdbc/org/postgresql/jdbc1/Jdbc1CallableStatement.java
       	jdbc/org/postgresql/jdbc1/Jdbc1PreparedStatement.java
       	jdbc/org/postgresql/jdbc1/Jdbc1Statement.java
       	jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java
       	jdbc/org/postgresql/jdbc2/Jdbc2CallableStatement.java
       	jdbc/org/postgresql/jdbc2/Jdbc2PreparedStatement.java
       	jdbc/org/postgresql/jdbc2/Jdbc2Statement.java
       	jdbc/org/postgresql/jdbc3/Jdbc3CallableStatement.java
       	jdbc/org/postgresql/jdbc3/Jdbc3PreparedStatement.java
       	jdbc/org/postgresql/jdbc3/Jdbc3Statement.java
       Added Files:
       	jdbc/org/postgresql/PGRefCursorResultSet.java
       	jdbc/org/postgresql/jdbc1/Jdbc1RefCursorResultSet.java
       	jdbc/org/postgresql/jdbc2/Jdbc2RefCursorResultSet.java
       	jdbc/org/postgresql/jdbc3/Jdbc3RefCursorResultSet.java
       	jdbc/org/postgresql/test/jdbc2/RefCursorTest.java
      5295fffc
    • Bruce Momjian's avatar
      Cleanup patch for exec() handling. · 721996d8
      Bruce Momjian authored
      721996d8
    • Bruce Momjian's avatar
    • Bruce Momjian's avatar
      SECOND ATTEMPT · 36fa2974
      Bruce Momjian authored
      Dump/read non-default GUC values for use by exec'ed backend, for Win32.
      36fa2974
    • Bruce Momjian's avatar
      Back out second part of patch. · 9f0d69f5
      Bruce Momjian authored
      9f0d69f5
  3. May 02, 2003
  4. May 01, 2003
  5. Apr 30, 2003
    • Tom Lane's avatar
      Update to describe new set of globally-known contexts planned for support · 0c57d69d
      Tom Lane authored
      of extended query features in new FE/BE protocol.  TransactionCommandContext
      is gone (PortalContext replaces it for some purposes), and QueryContext
      has taken on a new meaning (MessageContext plays its old role).
      0c57d69d
    • Tom Lane's avatar
      Infrastructure for deducing Param types from context, in the same way · aa282d44
      Tom Lane authored
      that the types of untyped string-literal constants are deduced (ie,
      when coerce_type is applied to 'em, that's what the type must be).
      Remove the ancient hack of storing the input Param-types array as a
      global variable, and put the info into ParseState instead.  This touches
      a lot of files because of adjustment of routine parameter lists, but
      it's really not a large patch.  Note: PREPARE statement still insists on
      exact specification of parameter types, but that could easily be relaxed
      now, if we wanted to do so.
      aa282d44
  6. Apr 29, 2003
  7. Apr 28, 2003
  8. Apr 27, 2003
  9. Apr 26, 2003
  10. Apr 25, 2003
Loading