PostgreSQLで経過年数、経過月数、経過日数を取得
extract(year from age(current_date, foo)) as "経過日数"
extract(year from age(current_date, foo)) * 12 + extract(month from age(current_date, foo)) as "経過月数"
extract(epoch from current_date - foo) / 86400 as "経過日数"
ネット検索でよく見かけるパターンが、「createdb -E UTF8 -T template0 -O owner -U user dbname」なんだけど、これで出来たデータベースはlc_collateがC、lc_ctypeもCってなって、言語固有のサポート(辞書順の並べ替えとか)が受けられないんじゃないかと思えてくる。
やはり「--locale=ja_JP.UTF8」も加えて「createdb -E UTF8 --locale=ja_JP.UTF8 -T template0 -O owner -U user dbname」なんじゃないのかなって思うのだけど、どっちがどう正しいのか判断できる情報にたどり着けず、落ち着かない気持ちになる。
サーバーがPostgreSQL 8.4系なのだけど、「--locale=ja_JP.UTF8」って書いたらエラーメッセージ(記録に残してない、すみません)が表示されて、「--locale=japanese」って書いたら通った。 コマンド全体として「createdb -E UTF8 --locale=japanese -T template0 -O owner -U user dbname」 本当にこれでいいんだろうか。
やりたいこととしては、文字エンコーディングはUTF8にしたい。 ただし、Windowsの扱うCP932を保存する目的で、いわゆる機種依存文字も含めてUnicodeとして保持されれば上出来なのだけど。
これまでの不勉強を呪うしか無いのだけど。
クライアントはWindowsパソコン(Windows XP)、サーバーはLinux系(CentOS)でPostgreSQL 8.4やPHP 4.2だったりする既存システム。 サーバーのデータベースダンプファイルをローカル(Windows 7のPostgreSQL 8.4)にリストアするときに、度々失敗するのがおかしいと思っていた。
具体的には、いわゆる機種依存文字がひっかかっていて、はしごの高橋(髙橋)が文字化けしているのだけはすぐわかった。
見つけては、サーバー上でPhpPgAdmin経由で文字化け原因を修正したり、ダンプファイルを直接修正していた。
もともと、シフトJISらしきエンコードでPostgreSQLを使っていた旧サーバーの能力不足のために、私が新サーバーを手配して構築して「引っ越し」させたのだけど、PostgreSQLでの言語エンコーディングを深く考えずにEUC_JPとしてしまったのも今考えるとあまりよろしくない。
SJIS(SHIFT_JIS)に含まれない機種依存文字を含むCP932でPHPなどで受け、それをEUC_JPでエンコーディングしているPostgreSQLデータベースに保存しているのだけど、pg_dumpallのダンプファイルや、PhpPgAdmin上では機種依存文字が文字化けして黒菱型に「?」の字形で表示されているので、私は完全に「文字化けが発生している!困った困った!」と思い込んでいた。
だけど、「pg_dump -E SJIS」などと出力エンコーディングをSJISに強制したところ、機種依存文字がそのまま化けずに得られることがわかった。
試しに、「pg_dumpall -l foobar -U foobar -w -v -f dumpall_`date +%Y%m%d%H%M`.dump」としていたものを、「pg_dump -E SJIS -F p -v --column-inserts -U foobar -f all_`date +%Y%m%d%H%M`.dump foobar」みたいにしてみたところ、SJISでダンプファイルを得ることが出来た。 あぁ、「--column-inserts」を書いてしまうと、かなり時間が掛かるので、普段はつけないか、「--inserts」にした方がいいようだ。
それって、CP932固有の文字がEUC_JPとして表せる文字がないだけで、元のSJISに戻せば元の文字になるってことなのかな。