> But is it really important? All Unixen that I know of handle process
> text segments on a page-by-page basis; pages that aren't actually being
> touched won't get swapped in. Thus, the unused maps will just sit on
> disk, whether they are part of the main executable or a separate file.
> I dou
Tatsuo Ishii writes:
> I use Makefile.shlib to create each shared object. This way is, I
> think, handy and portble. However, I need to make lots of subdirs for
> each encoding conversion function. Any suggestions?
Given Tom Lane's comment, I think that this would be a wasted effort.
Shared obje
On Thu, 16 Aug 2001, Tatsuo Ishii wrote:
> > I have a question, the PostgreSQL encoding name "KOI8" is KOI8-R or
> > KOI8-U or both? I need it for correct alias setting.
>
> I think it's KOI8-R. Oleg, am I correct?
YES
>
> P.S.
> I use Makefile.shlib to create each shared object. This way is,
On Thu, Aug 16, 2001 at 03:39:28PM +0900, Tatsuo Ishii wrote:
> > I have now some time for implement this my suggestion. Or is better
> > let down this for 7.2? You are right that it's trivial :-)
>
> I think you should target for 7.2.
>
> > Note: My motivate for this is that I have some multi
On Thu, Aug 16, 2001 at 10:22:48PM +0900, Tatsuo Ishii wrote:
> > I have a question, the PostgreSQL encoding name "KOI8" is KOI8-R or
> > KOI8-U or both? I need it for correct alias setting.
>
> I think it's KOI8-R. Oleg, am I correct?
>
> P.S.
> I use Makefile.shlib to create each shared obje
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Thanks. BTW, I'm working on for dynamically loading the Unicode
> conversion functions to descrease the runtime memory requirement. The
> reason why I want to do this is:
> o they are huge (--enable-unicode-conversion will increase ~1MB in the
> load mo
On Thu, Aug 16, 2001 at 03:39:28PM +0900, Tatsuo Ishii wrote:
>
> o they are huge (--enable-unicode-conversion will increase ~1MB in the
> load module size)
>
> o nobody will use all of them at once. For example most Japanese users
> are only interested in EUC/SJIS maps.
> --
Good idea.
I
> I have now some time for implement this my suggestion. Or is better
> let down this for 7.2? You are right that it's trivial :-)
I think you should target for 7.2.
> Note: My motivate for this is that I have some multi-language DB
>with Web interface and for current version of PG I m
> Finally, as I've mentioned before I'd like to try out the iconv interface.
> Might become an option in 7.2 even.
I'm curious how do you handle conversion between multibyte strings
and wide characters using iconv. This is necessary to implement
multibyte aware like, regex, char_length etc. funct
On Wed, Aug 15, 2001 at 05:16:42PM +0200, Peter Eisentraut wrote:
> Karel Zak writes:
>
> > before some time I was discuss with Tatsuo and Thomas about support
> > for synonyms of encoding names (for example allows to use
> > "ISO-8859-1" as the encoding name) and use binary search for searching
Tatsuo Ishii writes:
> However, I think we should focus on more fundamental issues
> than those trivial ones. Recently Thomas gave an idea how to deal with
> the internationalization (I18N) of PostgreSQL: create character set
> etc.
I haven't actually seen any real implementation proposal yet.
Karel Zak writes:
> before some time I was discuss with Tatsuo and Thomas about support
> for synonyms of encoding names (for example allows to use
> "ISO-8859-1" as the encoding name) and use binary search for searching
> in encoding names.
Funny, I was thinking the same thing last night...
A
On Wed, Aug 15, 2001 at 11:28:35PM +0900, Tatsuo Ishii wrote:
> Thank you for your suggestions. I'm not totally against your
> suggestions (for example, I'm not against the idea that changing all
> current encoding names to more "standard" ones for 7.2 if it's your
> concern). However, I think we
Thank you for your suggestions. I'm not totally against your
suggestions (for example, I'm not against the idea that changing all
current encoding names to more "standard" ones for 7.2 if it's your
concern). However, I think we should focus on more fundamental issues
than those trivial ones. Recen
Hi,
before some time I was discuss with Tatsuo and Thomas about support
for synonyms of encoding names (for example allows to use
"ISO-8859-1" as the encoding name) and use binary search for searching
in encoding names.
I mean that we can during this change a little clean up encoding
stuf
On Wed, 21 Feb 2001, Tatsuo Ishii wrote:
> Please understand there is no standard for charset/encoding names in
> SQL92/99 itself. The SQL standard just says "you can import any
> charset/encoding from anywhere if you can". Please correct me if I am
> wrong.
In SQL standards not, but all probab
> > But HTML meta tags used to use their own encoding names such as
> > x-euc-jp, x-sjis
>
> Not sure, my mozilla understand "ISO--x", "Shift-JIS" format too.
> But it's irrelevant, important is that something like "Latin2" or "SJIS"
> or "EUC_JP" are less standard names. And here aren't
> But HTML meta tags used to use their own encoding names such as
> x-euc-jp, x-sjis
Not sure, my mozilla understand "ISO--x", "Shift-JIS" format too.
But it's irrelevant, important is that something like "Latin2" or "SJIS"
or "EUC_JP" are less standard names. And here aren't HTML only,
> I a little work with encodings (Japanese, Latin(s)) and I see that
> PG use non-standard encoding names.
>
> Why is here SJIS instead Shift-JIS, EUC_JP intead EUC-JP,
> Latin2 instead ISO-8859-2 ?
>
> It is not good for example for applications that output data to HTML and
> needs set co
Hi,
I a little work with encodings (Japanese, Latin(s)) and I see that
PG use non-standard encoding names.
Why is here SJIS instead Shift-JIS, EUC_JP intead EUC-JP,
Latin2 instead ISO-8859-2 ?
It is not good for example for applications that output data to HTML and
needs set correct met
20 matches
Mail list logo
