1. 25 Aug, 2007 1 commit
    • Tom Lane's avatar
      Cleanup for some problems in tsearch patch: · 7351b5fa
      Tom Lane authored
      - ispell initialization crashed on empty dictionary file
      - ispell initialization crashed on affix file with prefixes but no suffixes
      - stop words file was run through pg_verify_mbstr, with database
        encoding, but it's supposed to be UTF-8; similar bug for synonym files
      - bunch of comments added, typos fixed, and other cleanup
      
      Introduced consistent encoding checking/conversion of data read from tsearch
      configuration files, by doing this in a single t_readline() subroutine
      (replacing direct usages of fgets).  Cleaned up API for readstopwords too.
      
      Heikki Linnakangas
      7351b5fa
  2. 23 Aug, 2007 5 commits
  3. 22 Aug, 2007 11 commits
  4. 21 Aug, 2007 16 commits
  5. 20 Aug, 2007 1 commit
  6. 19 Aug, 2007 3 commits
  7. 16 Aug, 2007 1 commit
  8. 15 Aug, 2007 2 commits
    • Tom Lane's avatar
      Arrange to cache a ResultRelInfo in the executor's EState for relations that · 817946bb
      Tom Lane authored
      are not one of the query's defined result relations, but nonetheless have
      triggers fired against them while the query is active.  This was formerly
      impossible but can now occur because of my recent patch to fix the firing
      order for RI triggers.  Caching a ResultRelInfo avoids duplicating work by
      repeatedly opening and closing the same relation, and also allows EXPLAIN
      ANALYZE to "see" and report on these extra triggers.  Use the same mechanism
      to cache open relations when firing deferred triggers at transaction shutdown;
      this replaces the former one-element-cache strategy used in that case, and
      should improve performance a bit when there are deferred triggers on a number
      of relations.
      817946bb
    • Tom Lane's avatar
      Repair problems occurring when multiple RI updates have to be done to the same · 9cb84097
      Tom Lane authored
      row within one query: we were firing check triggers before all the updates
      were done, leading to bogus failures.  Fix by making the triggers queued by
      an RI update go at the end of the outer query's trigger event list, thereby
      effectively making the processing "breadth-first".  This was indeed how it
      worked pre-8.0, so the bug does not occur in the 7.x branches.
      Per report from Pavel Stehule.
      9cb84097