Re: pl/perl and utf-8 in sql_ascii databases
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: pl/perl and utf-8 in sql_ascii databases |
Дата | |
Msg-id | 20120628.140422.06815819.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: pl/perl and utf-8 in sql_ascii databases (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pl/perl and utf-8 in sql_ascii databases
|
Список | pgsql-hackers |
Hello, thank you for your sugestion. > > I agree. That is the fundamental question. I've coded just for my > > fun but I don't see not so much signicance to do that. We might > > omit the test for this which is non-ciritical and corner cases. > > We need these tests to work on Windows too, so fancy gmake tricks are > probably not the way to deal with varying results. Hmm. I understand that you suggested that we should do this in normal regression test. Ok. Since there found to be only two patterns in the regression test. The fancy thing is no more needed. I will unfold them and make sure to work on mingw build environment. And for one more environment, on the one with VC++.. I'll need a bit longer time to make out what vcregress.pl does. On the other things, I will decide as following and sent to committer as soon as the above is finished. - The main patch fixes the sql-ascii handling itself shoud ported into 9.2 and 9.1. Someone shoud work for this. (me?) - The remainder of the patch whic fixes the easy fixable leakes of palloc'ed memory won't be ported into 9.1. This is onlyfor 9.3dev. - The patch for 9.3dev will be provided with the new regression test. It will be easily ported into 9.1 and 9.2 and thereseems to be no problem technically, but a bit unsure from the other points of view... regards, -- Kyotaro Horiguchi NTT Open Source Software Center == My e-mail address has been changed since Apr. 1, 2012.
В списке pgsql-hackers по дате отправления: