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$ du4 ./CVS7
./Unicode/CVS9541 ./Unicode15805 .
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 pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026