Re: pl/perl and utf-8 in sql_ascii databases

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: pl/perl and utf-8 in sql_ascii databases
Дата
Msg-id 20120622.153139.145646934.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: pl/perl and utf-8 in sql_ascii databases  (Alex Hunsaker <badalex@gmail.com>)
Ответы Re: pl/perl and utf-8 in sql_ascii databases  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hello.

> > The attached ugly patch does it. We seem should put NO_LOCALE=1
> > on the 'make check' command line for the encodings not compatible
> > with the environmental locale, although it looks work.
> 
> +REGRESS_LC0 = $(subst .sql,,$(shell cd sql; ls plperl_lc_$(shell echo
snip.
> Hrm, that's quite cute. I dunno if there is a more cannon way of doing
> the above-- but it seems to work. I'm not sure this regression test is
> worth it. I'm thinking maybe we should just remove
> theegressionegression test instead.

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.

I'll leave it to your decision whether to do that.

> There is a minor issue with the patch where
> sql/plperl_lc_sql_ascii.sql contains the text "plperl_lc.sql". After
> copying sql/plperl_lc.sql to sql/plperl_lc_sql_ascii.sql everything
> worked as described.

Ah. It is what was a simbolic link. I made the patch with doubt
whether symlink could be encoded into diff, and saw the doubious
result but left as it is :-p. I leaned that no meaningful
symbolic-link cannot be used in source tree managed by git.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

== My e-mail address has been changed since Apr. 1, 2012.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: D'Arcy Cain
Дата:
Сообщение: Re: COMMUTATOR doesn't seem to work
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Catalog/Metadata consistency during changeset extraction from wal