1. 14 5月, 2000 4 次提交
  2. 13 5月, 2000 8 次提交
    • T
      e8e7b630
    • B
      Fix the off by one errors in ResultSet from 6.5.3, and more. · 2cfb14e8
      Bruce Momjian 提交于
      I'm including a diff of
      postgresql-7.0/src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java.
      I've clearly marked all the fixes I did. Would *someone* who has access
      to the cvs please put this in?
      
      Joseph Shraibman
      2cfb14e8
    • B
      This is the second time I've answered this exact same problem in two · a28f1177
      Bruce Momjian 提交于
      days.  It seems to be a FAQ, and I think I know why. When creating a 'c'
      language function, CREATE FUNCTION is fed the shared object filename,
      and seems to succeed. Only when trying to use the function is an error
      thrown, by which time the coder thinks something's wrong with executing
      the code, not with loading it.
      
      I think I once saw it proposed to load shared objects at function creation
      time, but that idea was shot down on the grounds of resident memory bloat,
      ISTR. Here's a patch for a compromise: all it does is stat() the file,
      just like the loader code does, so that the errors caused by non existent
      files, and no directory 'x' permissions (the most common ones, it seems),
      get caught while the developer is still thinking about code loading. It
      doesn't catch all errors (like the code not being readable by the postgres
      user) but seems to catch the most common, without actually opening the file.
      
      What do you think?
      
      Ross
      a28f1177
    • B
      Update TODO list. · 5e02f6b6
      Bruce Momjian 提交于
      5e02f6b6
    • B
      Remove cluster TODO e-mail file · e9e42f6f
      Bruce Momjian 提交于
      e9e42f6f
    • B
      Back out -\?. Didn't look good to Peter. · 40c992c7
      Bruce Momjian 提交于
      40c992c7
    • P
      /home/peter/commit-msg · 9d31e3a9
      Peter Eisentraut 提交于
      9d31e3a9
    • T
      Squash some more CLUSTER bugs. Never has worked on multiple-column · 475cb157
      Tom Lane 提交于
      indexes, apparently, nor on functional indexes with more than one input
      column (force of natts = 1 was in the wrong branch of IF statement).
      Coredumped if source relation contained any uncommitted tuples, due to
      failure to test for success return from heap_fetch.  Fetched tuple
      was passed directly to heap_insert, which clobbers the TID and commit
      status in the tuple header it's given, which meant that the source
      relation's tuples all got trashed as the copy proceeded.  Abort partway
      through, and you're left with a lot of missing tuples.
      I wonder what else is lurking here ...
      475cb157
  3. 12 5月, 2000 9 次提交
  4. 11 5月, 2000 5 次提交
  5. 10 5月, 2000 4 次提交
  6. 09 5月, 2000 2 次提交
  7. 07 5月, 2000 2 次提交
  8. 06 5月, 2000 3 次提交
  9. 05 5月, 2000 3 次提交