Tatsuo Ishii wrote:
> Here is my proposal for new CREATE CONVERSION which makes it possible
> to define new encoding conversion mapping between two encodings on the
> fly.
>
> The background:
>
> We are getting having more and more encoding conversion tables. Up to
> now, they reach to 385352 source lines and over 3MB in compiled forms
> in total. They are statically linked to the backend. I know this
> itself is not a problem since modern OSs have smart memory management
> capabilities to fetch only necessary pages from a disk. However, I'm
> worried about the infinite growing of these static tables. I think
> users won't love 50MB PostgreSQL backend load module.
Yes, those conversion tables are getting huge in the tarball too:
$ pwd
/pg/backend/utils/mb
$ du
4 ./CVS
7 ./Unicode/CVS
9541 ./Unicode
15805 .
Look at these two file alone:
-rw-r--r-- 1 postgres wheel 1427492 Jun 13 04:28 gb18030_to_utf8.map
-rw-r--r-- 1 postgres wheel 1427492 Jun 13 04:28 utf8_to_gb18030.map
If we can make these loadable, that would be good. What would be really
interesting is if we could split these out into a separate
directory/project so development on those could take place in an
independent way. This would probably stimulate even more encoding
options for users.
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
