1. 01 Aug, 1998 1 commit
  2. 27 Jul, 1998 1 commit
  3. 26 Jul, 1998 1 commit
    • Marc G. Fournier's avatar
      · 5979d738
      Marc G. Fournier authored
      From: t-ishii@sra.co.jp
      
      As Bruce mentioned, this is due to the conflict among changes we made.
      Included patches should fix the problem(I changed all MB to
      MULTIBYTE). Please let me know if you have further problem.
      
      P.S. I did not include pathces to configure and gram.c to save the
      file size(configure.in and gram.y modified).
      5979d738
  4. 24 Jul, 1998 1 commit
    • Marc G. Fournier's avatar
      · bf00bbb0
      Marc G. Fournier authored
      I really hope that I haven't missed anything in this one...
      
      From: t-ishii@sra.co.jp
      
      Attached are patches to enhance the multi-byte support.  (patches are
      against 7/18 snapshot)
      
      * determine encoding at initdb/createdb rather than compile time
      
      Now initdb/createdb has an option to specify the encoding. Also, I
      modified the syntax of CREATE DATABASE to accept encoding option. See
      README.mb for more details.
      
      For this purpose I have added new column "encoding" to pg_database.
      Also pg_attribute and pg_class are changed to catch up the
      modification to pg_database.  Actually I haved added pg_database_mb.h,
      pg_attribute_mb.h and pg_class_mb.h. These are used only when MB is
      enabled. The reason having separate files is I couldn't find a way to
      use ifdef or whatever in those files. I have to admit it looks
      ugly. No way.
      
      * support for PGCLIENTENCODING when issuing COPY command
      
      commands/copy.c modified.
      
      * support for SQL92 syntax "SET NAMES"
      
      See gram.y.
      
      * support for LATIN2-5
      * add UNICODE regression test case
      * new test suite for MB
      
      New directory test/mb added.
      
      * clean up source files
      
      Basic idea is to have MB's own subdirectory for easier maintenance.
      These are include/mb and backend/utils/mb.
      bf00bbb0
  5. 20 Jul, 1998 1 commit
  6. 15 Jun, 1998 2 commits
  7. 27 Apr, 1998 1 commit
    • Bruce Momjian's avatar
      This patch... · 09baa3cc
      Bruce Momjian authored
      1. Removes the unnecessary "#define AbcRegProcedure 123"'s from
      pg_proc.h.
      
      2. Changes those #defines to use the names already defined in
      fmgr.h.
      
      3. Forces the make of fmgr.h in backend/Makefile instead of having
      it
         made as a dependency in access/common/Makefile  *hack*hack*hack*
      
      4. Rearranged the #includes to a less helter-skelter arrangement,
      also
          changing <file.h> to "file.h" to signify a non-system header.
      
      5. Removed "pg_proc.h" from files where its only purpose was for
      the
         #defines removed in item #1.
      
      6. Added "fmgr.h" to each file changed for completeness sake.
      
      Turns out that #6 was not necessary for some files because fmgr.h
      was being included in a roundabout way SIX levels deep by the first
      include.
      
      "access/genam.h"
       ->"access/relscan.h"
         ->"utils/rel.h"
           ->"access/strat.h"
             ->"access/skey.h"
      	 ->"fmgr.h"
      
      So adding fmgr.h really didn't add anything to the compile, hopefully
      just made it clearer to the programmer.
      
      S Darren.
      09baa3cc
  8. 26 Feb, 1998 1 commit
  9. 23 Feb, 1998 1 commit
    • Marc G. Fournier's avatar
      From: Jan Wieck <jwieck@debis.com> · 6c7c6d0c
      Marc G. Fournier authored
          The diff looks so simple and easy. But to find it wasn't fun.
      
          It must have been there for a long time. What happened:
      
          When a tuple in one of some central catalogs was updated, the
          referenced  relation  got flushed, so it would be reopened on
          the next access (to reflect new  triggers,  rules  and  table
          structure changes into the relation cache).
      
          Some  data  (the  tupleDescriptor e.g.) is used in the system
          cache too. So when a relation is subject to the system cache,
          this  must know too that a cached system relation got flushed
          because the tupleDesc data gets freed during the flush!
      
          For the GRANT/REVOKE on pg_class it was  slightly  different.
          There  is some local data in inval.c that gets initialized on
          the first invalidation of a tuple in some  central  catalogs.
          This  needs a SysCache lookup in pg_class. But when the first
          of all commands is a GRANT on pg_class,  exactly  the  needed
          tuple is the one actually invalidated. So I added little code
          snippets that the initialization of the  local  variables  in
          inval.c will already happen during InitPostgres().
      6c7c6d0c
  10. 31 Jan, 1998 1 commit
  11. 15 Jan, 1998 1 commit
    • PostgreSQL Daemon's avatar
      Thank god for searchable mail archives. · baef78d9
      PostgreSQL Daemon authored
      Patch by: wieck@sapserv.debis.de (Jan Wieck)
      
         One  of  the design rules of PostgreSQL is extensibility. And
         to follow this rule means (at least for me) that there should
         not  only  be a builtin PL.  Instead I would prefer a defined
         interface for PL implemetations.
      baef78d9
  12. 14 Jan, 1998 1 commit
  13. 07 Jan, 1998 1 commit
  14. 05 Jan, 1998 1 commit
  15. 21 Nov, 1997 1 commit
  16. 20 Nov, 1997 1 commit
  17. 17 Nov, 1997 1 commit
  18. 02 Nov, 1997 1 commit
  19. 25 Oct, 1997 1 commit
  20. 18 Sep, 1997 1 commit
  21. 12 Sep, 1997 1 commit
  22. 08 Sep, 1997 2 commits
  23. 07 Sep, 1997 1 commit
  24. 01 Sep, 1997 1 commit
  25. 22 Aug, 1997 1 commit
  26. 21 Aug, 1997 2 commits
  27. 20 Aug, 1997 1 commit
  28. 19 Aug, 1997 2 commits
  29. 18 Aug, 1997 1 commit
  30. 12 Aug, 1997 1 commit
  31. 03 Aug, 1997 1 commit
  32. 28 Jul, 1997 1 commit
  33. 04 Jun, 1997 1 commit
  34. 22 May, 1997 1 commit
    • Vadim B. Mikheev's avatar
      RelationPurgeLocalRelation(): · c9be1bcc
      Vadim B. Mikheev authored
                  /*
                   * RelationFlushRelation () below will flush relation information
                   * from the cache. We must call smgrclose to flush relation
                   * information from SMGR & FMGR, too. We assume that for temp
                   * relations smgrunlink is already called by heap_destroyr
                   * and we skip smgrclose for them.          - vadim 05/22/97
                   */
                  smgrclose(reln->rd_rel->relsmgr, reln);
      
       - it avoids memory leaks in SMGR & VFD.
      
      RelationFlushRelation():
         there is no more call FileInvalidate(RelationGetSystemPort(relation));
         - invalid (FileInvalidate() expects File, not SMGR' fd)
         - unuseful anyway.
      c9be1bcc
  35. 20 May, 1997 1 commit
  36. 27 Nov, 1996 1 commit