1. 18 7月, 2002 1 次提交
    • T
      I have committed many support files for CREATE CONVERSION. Default · eb335a03
      Tatsuo Ishii 提交于
      conversion procs and conversions are added in initdb. Currently
      supported conversions are:
      
      UTF-8(UNICODE) <--> SQL_ASCII, ISO-8859-1 to 16, EUC_JP, EUC_KR,
      		    EUC_CN, EUC_TW, SJIS, BIG5, GBK, GB18030, UHC,
      		    JOHAB, TCVN
      
      EUC_JP <--> SJIS
      EUC_TW <--> BIG5
      MULE_INTERNAL <--> EUC_JP, SJIS, EUC_TW, BIG5
      
      Note that initial contents of pg_conversion system catalog are created
      in the initdb process. So doing initdb required is ideal, it's
      possible to add them to your databases by hand, however. To accomplish
      this:
      
      psql -f your_postgresql_install_path/share/conversion_create.sql your_database
      
      So I did not bump up the version in cataversion.h.
      
      TODO:
      Add more conversion procs
      Add [CASCADE|RESTRICT] to DROP CONVERSION
      Add tuples to pg_depend
      Add regression tests
      Write docs
      Add SQL99 CONVERT command?
      --
      Tatsuo Ishii
      eb335a03
  2. 13 6月, 2002 1 次提交
  3. 06 3月, 2002 1 次提交
    • B
      Change made to elog: · 92288a1c
      Bruce Momjian 提交于
      o  Change all current CVS messages of NOTICE to WARNING.  We were going
      to do this just before 7.3 beta but it has to be done now, as you will
      see below.
      
      o Change current INFO messages that should be controlled by
      client_min_messages to NOTICE.
      
      o Force remaining INFO messages, like from EXPLAIN, VACUUM VERBOSE, etc.
      to always go to the client.
      
      o Remove INFO from the client_min_messages options and add NOTICE.
      
      Seems we do need three non-ERROR elog levels to handle the various
      behaviors we need for these messages.
      
      Regression passed.
      92288a1c
  4. 05 3月, 2002 1 次提交
    • B
      > Tatsuo Ishii wrote: · a8bd7e1c
      Bruce Momjian 提交于
      > > > > It was made to cope with encoding such as an Asian bloc in 7.2Beta2.
      > > > >
      > > > > Added ServerEncoding
      > > > >         Korean (JOHAB), Thai (WIN874),
      > > > >         Vietnamese (TCVN), Arabic (WIN1256)
      > > > >
      > > > > Added ClientEncoding
      > > > >         Simplified Chinese (GBK), Korean (UHC)
      > > > >
      > > > >
      > > > >
      > http://www.sankyo-unyu.co.jp/Pool/postgresql-7.2b2.newencoding.diff.tar.gz
      > > > > (608K)
      > > >
      > > > Looks good.  I need some people to review this for me.
      > >
      > > For me they look good too. The only missing part is a
      > > documentation. I will ask him to write it up. If he couldn't, I will
      > > do it for him.
      > > > The diff is 3mb
      > > > but appears to address only additions to multibyte.  I have attached a
      > > > list of files it modifies.  Also, look at the sizes of the mb/
      > > > directory.  It is getting large:
      > > >
      > > >   4       ./CVS
      > > >   6       ./Unicode/CVS
      > > >   3433    ./Unicode
      > > >   6197    .
      > >
      > > Yes. We definitely need the on-the-fly encoding addition capability:
      > > i.e. CREATE CHRACTER SET in the future...
      > > --
      > > Tatsuo Ishii
      > >
      > >
      
      Address chainge.
      
      http://www.sankyo-unyu.co.jp/Pool/postgresql-7.2.newencoding.diff.gz
      
      Add PsqlODBC and document ...etc patch.
      
      Eiji Tokuya
      a8bd7e1c
  5. 06 11月, 2001 1 次提交
  6. 28 10月, 2001 1 次提交
  7. 25 10月, 2001 1 次提交
  8. 16 10月, 2001 1 次提交
    • T
      Ok, here is the modified encoding table (column1 is the standard name, · cfe01796
      Tatsuo Ishii 提交于
      2 is our "official" name, and 3 is alias). If there's no objection, I
      will change them.
      
      ASCII		SQL_ASCII
      UTF-8		UNICODE		UTF_8
      MULE-INTERNAL	MULE_INTERNAL
      ISO-8859-1	LATIN1		ISO_8859_1
      ISO-8859-2	LATIN2		ISO_8859_2
      ISO-8859-3	LATIN3		ISO_8859_3
      ISO-8859-4	LATIN4		ISO_8859_4
      ISO-8859-5	ISO_8859_5
      ISO-8859-6	ISO_8859_6
      ISO-8859-7	ISO_8859_7
      ISO-8859-8	ISO_8859_8
      ISO-8859-9	LATIN5		ISO_8859_9
      ISO-8859-10	LATIN6		ISO_8859_10
      ISO-8859-13	LATIN7		ISO_8859_13
      ISO-8859-14	LATIN8		ISO_8859_14
      ISO-8859-15	LATIN9		ISO_8859_15
      ISO-8859-16	LATIN10		ISO_8859_16
      cfe01796
  9. 11 10月, 2001 1 次提交
  10. 25 9月, 2001 1 次提交
  11. 22 9月, 2001 1 次提交
  12. 11 9月, 2001 1 次提交
  13. 06 9月, 2001 1 次提交
    • T
      Commit Karel's patch. · 22776711
      Tatsuo Ishii 提交于
      -------------------------------------------------------------------
      Subject: Re: [PATCHES] encoding names
      From: Karel Zak <zakkr@zf.jcu.cz>
      To: Peter Eisentraut <peter_e@gmx.net>
      Cc: pgsql-patches <pgsql-patches@postgresql.org>
      Date: Fri, 31 Aug 2001 17:24:38 +0200
      
      On Thu, Aug 30, 2001 at 01:30:40AM +0200, Peter Eisentraut wrote:
      > > 		- convert encoding 'name' to 'id'
      >
      > I thought we decided not to add functions returning "new" names until we
      > know exactly what the new names should be, and pending schema
      
       Ok, the patch not to add functions.
      
      > better
      >
      >     ...(): encoding name too long
      
       Fixed.
      
       I found new bug in command/variable.c in parse_client_encoding(), nobody
      probably never see this error:
      
      if (pg_set_client_encoding(encoding))
      {
      	elog(ERROR, "Conversion between %s and %s is not supported",
                           value, GetDatabaseEncodingName());
      }
      
      because pg_set_client_encoding() returns -1 for error and 0 as true.
      It's fixed too.
      
       IMHO it can be apply.
      
      		Karel
      PS:
      
          * following files are renamed:
      
      src/utils/mb/Unicode/KOI8_to_utf8.map  -->
              src/utils/mb/Unicode/koi8r_to_utf8.map
      
      src/utils/mb/Unicode/WIN_to_utf8.map  -->
              src/utils/mb/Unicode/win1251_to_utf8.map
      
      src/utils/mb/Unicode/utf8_to_KOI8.map -->
              src/utils/mb/Unicode/utf8_to_koi8r.map
      
      src/utils/mb/Unicode/utf8_to_WIN.map -->
              src/utils/mb/Unicode/utf8_to_win1251.map
      
         * new file:
      
      src/utils/mb/encname.c
      
         * removed file:
      
      src/utils/mb/common.c
      
      --
       Karel Zak  <zakkr@zf.jcu.cz>
       http://home.zf.jcu.cz/~zakkr/
      
       C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
      22776711
  14. 28 5月, 2001 1 次提交
  15. 29 4月, 2001 1 次提交
  16. 22 3月, 2001 1 次提交
  17. 11 2月, 2001 1 次提交
  18. 10 2月, 2001 1 次提交
    • T
      Restructure the key include files per recent pghackers discussion: there · d08741ea
      Tom Lane 提交于
      are now separate files "postgres.h" and "postgres_fe.h", which are meant
      to be the primary include files for backend .c files and frontend .c files
      respectively.  By default, only include files meant for frontend use are
      installed into the installation include directory.  There is a new make
      target 'make install-all-headers' that adds the whole content of the
      src/include tree to the installed fileset, for use by people who want to
      develop server-side code without keeping the complete source tree on hand.
      Cleaned up a whole lot of crufty and inconsistent header inclusions.
      d08741ea
  19. 17 11月, 2000 1 次提交
  20. 30 10月, 2000 1 次提交
  21. 27 10月, 2000 1 次提交
  22. 12 10月, 2000 1 次提交
  23. 27 8月, 2000 1 次提交
  24. 28 6月, 2000 1 次提交
    • T
      First phase of memory management rewrite (see backend/utils/mmgr/README · 1aebc361
      Tom Lane 提交于
      for details).  It doesn't really do that much yet, since there are no
      short-term memory contexts in the executor, but the infrastructure is
      in place and long-term contexts are handled reasonably.  A few long-
      standing bugs have been fixed, such as 'VACUUM; anything' in a single
      query string crashing.  Also, out-of-memory is now considered a
      recoverable ERROR, not FATAL.
      Eliminate a large amount of crufty, now-dead code in and around
      memory management.
      Fix problem with holding off SIGTRAP, SIGSEGV, etc in postmaster and
      backend startup.
      1aebc361
  25. 20 5月, 2000 1 次提交
  26. 13 4月, 2000 1 次提交
  27. 13 1月, 2000 1 次提交
  28. 12 7月, 1999 1 次提交
  29. 26 5月, 1999 4 次提交
  30. 26 4月, 1999 1 次提交
  31. 24 3月, 1999 1 次提交
  32. 03 2月, 1999 1 次提交
    • B
      Included patches make some enhancements to the multi-byte support. · a7ad43cd
      Bruce Momjian 提交于
      o allow to use Big5 (a Chinese encoding used in Taiwan) as a client
        encoding. In this case the server side encoding should be EUC_TW
      
      o add EUC_TW and Big5 test cases to the regression and the mb test
        (contributed by Jonah Kuo)
      
      o fix mistake in include/mb/pg_wchar.h. An encoding id for EUC_TW was
        not correct (was 3 and now is 4)
      
      o update documents (doc/README.mb and README.mb.jp)
      
      o update psql helpfile (bin/psql/psqlHelp.h)
      
      --
      Tatsuo Ishii
      t-ishii@sra.co.jp
      a7ad43cd
  33. 14 12月, 1998 1 次提交
  34. 01 9月, 1998 1 次提交
  35. 24 8月, 1998 1 次提交
    • B
      o note that now pg_database has a new attribuite "encoding" even · c0b01461
      Bruce Momjian 提交于
      if MULTIBYTE is not enabled. So be sure to run initdb.
      
      o these patches are made against the latest source tree (after
      Bruce's massive patch, I think) BTW, I noticed that after running
      regression, the oid field of pg_type seems disappeared.
      
      	regression=> select oid from pg_type; ERROR:  attribute
      	'oid' not found
      
      this happens after the constraints test. This occures with/without
      my patches. strange...
      
      o pg_database_mb.h, pg_class_mb.h, pg_attribute_mb.h are no longer
      used, and shoud be removed.
      
      o GetDatabaseInfo() in utils/misc/database.c removed (actually in
      #ifdef 0). seems nobody uses.
      
      t-ishii@sra.co.jp
      c0b01461
  36. 24 7月, 1998 1 次提交
    • M
      · bf00bbb0
      Marc G. Fournier 提交于
      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
  37. 19 7月, 1998 1 次提交