PHPのテクメモ

MySQL同様、PostgreSQLにもウェブベースの管理画面がある。phpPgAdminだ。以前（5年位前）PostgreSQLを使っていたときは知らなかったのだが、最近はデータの中身を見るときなど、便利なので使うことがある。今回は位置情報以外のテーブル操作はphpPgAdminを使うことにした。

行の操作では使ったことがあったけど、phpPgAdminでテーブルを作ったりしたことがなかったのでいきなり躓いた。テーブルを作ろうとするといきなりエラーが出てしまった。

少なくとも一つのフィールドを指定しなければなりません。

意味わかんない。でも、ウェブで調べて解決。どうやらカラムの追加でintegerを設定する際、長さを指定しているとこのエラーが出るらしい。ためしにintegerを設定したカラムの長さを空欄にするとテーブルは作成できた。

phpPgAdminで、例えばtext型を指定すると、そのカラムで入力する必要がない部分（長さ）の入力ボックスはグレーアウトして入力できなくなる。だったらinteger型でも同じようにできなかったのかね。しかしそれにしてもエラーメッセージがまったく的を得ていない。やっぱりphpMyAdminのように使い込まれていないからなのだろうか。当分phpPgAdminの使い方でも迷いそうだ。でもまぁ、これもまた勉強、か。

Windowsな環境で試しているときは、所詮ローカルな環境だからユーザとか気にせずテストしていたけれど、さすがに外部公開するサーバではまずいので、ユーザを追加して使用することになる。ユーザの追加はpostgresユーザになって「createuser -P」。あとpg_hba.confでPostgreSQLへの接続設定。ここまでは一般的なことで、別にPostGISに限った話ではない（いや、結局全てPostGISに限ったことではないのだけれど）。

で、早速新しいユーザでデータベースを作ろうとしてみた。コマンドは-Tオプションで新しく作ったテンプレートデータベースを指定する。しかしエラーで作ることができない。

createdb: database creation failed: ERROR:  permission denied to copy database “template_postgis”

どうやらtemplate_postgisへのアクセス権がないからだめだ、といわれているらしい。そこでtemplate_postgisのアクセス権について考えることにした。まず、データベースの状態を知るために、postgresユーザになって以下のコマンドを実行。

SELECT * FROM pg_database;

これでデータベースの状態（？）を見ることができるのだが、デフォルトのデータベーステンプレートであるtemplate1と比較してみた。その中でdatistemplateなるカラムがあり、そこが違うようだ。読んで字のごとく「データがテンプレートか否か」ということらしい。これをtureにしてやればよさそうなので、以下のコマンドを発行。

update pg_database set datistemplate=true where datname=’template_postgis’

これで多分テンプレート化できた（と思う）。その後、元のユーザになってデータベースを作成したところ、問題なく作成できた。ほっとして、データベースの中身を確認し、二つのテーブルが作成されていたので「よしよし」と思い、いちおうテーブルの中身を確認しようとselect文を発行しようとしたところまたエラー。どうやらデータベースのテンプレート可はできたものの、中身のテーブルのオーナーはpostgresのままらしい。データベース作成時にデフォルトで中のテーブルのオーナーも設定してくれる方法がわからない。しかたないので、postgresユーザになってデータベースにログインし、grantコマンドで新ユーザにフルアクセスで権限を与えた。

これでようやく新ユーザでPostGISなデータベースを使えるようになった（はず）。ためしにデータベースにログインして「SELECT postgis_version();」コマンドを発行したら、ちゃんと応答を返してくれた。

postgis_version
—————————————
1.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
(1 row)

半日とは言わないまでも、4、5時間くらいかかった。でも使えるようになってよかった・・・。使ったのはココのサイト。

https://projects.commandprompt.com/public/pgcore

PostgreSQLに関する最新の安定版RPMを各種ディストリビューションにむけて提供するという、なんとも神様みたいなサイト。いっそのことPostgreSQL本体もアップグレードしちゃったほうがいいわけだが、あくまで必要最小限を心がけた。ページの中ほどに「Direct Download」というのがあるのでそこをクリックし、該当するPostgreSQLのバージョンを選択する。CentOS5の場合は8.1。各バージョンにコメントがあってちょっと楽しい。ちなみに7.3はEOL（End of Life）。つまり「お前はもう死んでいる」ってやつですな。いちおう8.1はDecent release（相応）らしいが本当だかどうだか。

そして次の画面でredhatを選択。いろいろ出てくるがCentOS5をつかっているということで（かつx86_64）、rhel-5-x86_64を選ぶ。PostgreSQLに関するrpmがずらーっと一覧で表示される。まずは試しにpostgisをダウンロードし、rpmでインストールしてみた（postgis-1.3.6-1.rhel5.x86_64.rpm）。しかし「依存関係を解消してくださいよ」とエラーが出る。これは手作業では面倒だ。そこで、必殺技とでも言うべきyumを使うことになるのだが、これにはpgdg-centos-8.1-4.noarch.rpmを使う。まずはダウンロードしてインストール。

「yum install postgis」としてみたらPROJが必要といわれた。PROJはこちらのサイトになかったので、あらためてrpmfindからダウンロードしてインストールした。インストールしたのは以下の二つ。

proj-4.5.0-1.el5.rf.x86_64.rpm
proj-devel-4.5.0-1.el5.rf.x86_64.rpm

二つをインストールして再度「yum」。するとあら不思議。今まではyumしても「PostGISなんて知らないよ」といわれていたのに、手のひらを返したように、依存関係も解消してくれて、インストールしますかときいてくれる（「yum install postgis」とコマンドをうった）。もちろん「y」。これで無事PostGISをインストールできた。

もちろんここまではrpmfindだけでもできたけれど、ここから先が重要。ちなみにこの時点でデータベースにはtemplate_postgisが出来上がっている状態だった（それだけですごい進歩）。ちなみに入門書やブログなどで書かれているcrealtelangコマンドも入力された状態になっているようだ。いったんデータベースの中身をみてみたが、残念ながら何もはいっていない。関数なしの状態だ。そこは手動でやらなくてはいけないらしい。

本来なら「lwpostgis.sql」「spatial_ref_sys.sql」の二つのSQL文を実行するのだが、前述のPostGISのインストールでできたSQL文はファイル名が違っていた。

psql -d template_postgis -f /usr/share/pgsql/contrib/lwpostgis-64.sql
psql -d template_postgis -f /usr/share/pgsql/contrib/lwpostgis_upgrade-64.sql
psql -d template_postgis -f /usr/share/pgsql/contrib/postgis_comments.sql
psql -d template_postgis -f /usr/share/pgsql/contrib/spatial_ref_sys.sql

おまけに4つもSQL文があったが、いちおうそれらしい順番で流してみた。途中数行程度エラーが出ているような感じだが、とりあえず9割以上OKだったので、よしとすることにした！。完了！。

あと、必要最小限の関数が使えるかどうかチェックする必要はあるけれど、何はともあれ、インストールできたっぽいのでほっとした。よかった。

さて、一通りPostGISのインストールも終了したけれど・・・結論から言うと、うまくいかなかった。インストール自体は成功したのだが、PostGISなデータベースを作成することができなかった。便利なコマンドがインストールされているのはとてもうれしかったのだが（mktemplate_gisとか）、そのコマンドがエラーのため途中でとまってしまう。いろいろ試したり調べたりしたけど、うまくいきそうにないので、別の方法を考えることにした。

そもそも、それ以前に間違えていたところがあって、x86_64環境をインストールしなくてはいけなかったっぽい。なぜ気づいたかというと、いろいろインストールしてみたわけだが、rpm -qa | grep postgresとコマンドをたたくと、なぜかpostgresql-develとか2つも入ってるし！。よくよく調べてみたら、i386とx86_64はそれぞれインストールできるらしくて、どうもごちゃまぜになっている感じ。ウェブで検索すると以下のコマンドで環境を表示させることができる。

rpm -q –queryformat “%{name}.%{arch}\n” postgresql-devel

出力のフォーマットを名前+環境で表示しなさいということなのだが、見事に二つ「.i386」と「.x86_64」がインストールされていた。っていうか、借りてるサーバの環境くらい調べておけばよかった。アンインストールはこのコマンドでOK。

rpm -e postgresql-devel.i386

多分、他でも応用できる。

そして、コレに基づいて調べたら、さっきインストールしたのはi386版。しかもRedHat向けじゃないものまで入れてるっぽい。というわけでせっせとrpm -eにてアンインストール。かなりの時間を無駄にしてしまった。

そして、めげずにいろいろ試した。実は、ソースからコンパイルすればうまくいくだろうと思ってやってみたけど、make installまでは成功するけど、その後PostGISなデータベースの作成でエラーが出てしまう。久々に長時間格闘してうまくいかないので、クライアントに「ごめんなさい」と言おうかとも思ったけど、いちおうもう少しがんばってみて、なんとか解決する方法を見つけることができた。しかもyumインストールできた！。

方法は後日掲載予定。

これまではお試しということでWindowsで試していたが、本格的にLinuxで構築することになった（別にWindowsはオチャラケでLinuxがマジメという意味ではない）。Windowsではインストーラから簡単にpostgreSQLからPostGISまでインストールできるけど、Linuxではそうは簡単にいかない（とわかってはいたのだが・・・）。

今回のディストリビューションはCentOS5。最近はネットワーク関係の仕事は一切していなかったので、OSなんて気にも留めていなかったのだが、Ubuntuとかいろいろなディストリビューションがあるらしい（名前は聞いていたけど、ぜんぜん興味なし）。まぁ、CentOS5は一般的だし、RedHatの正統な流れだし（いや、正統なのはRedHatなわけだが）、契約したサーバがCentOS5だったし、CentOS5が使えるサーバが多いし、慣れ親しんでいるし・・・。他のOS使ったことないから、もっぱらCentOSなだけなんだけど。

まず調べたが、当然のごとくデフォルトのyumリポジトリにはPostGISは存在しない。よって必然的にサードパーティー。ウェブでいろいろ検索してみたら「試験管のなかのコード」さんの記事でCentOS5とPostgreSQLのインストール記事があり、そちらでサードパーティーからのPostgreSQLインストールが紹介されていた。そこにpostgisの文字が！。しかもyumで管理できるみたいだし「こりゃいいや」と思ってやってみたけど、どうもうまくいってくれなかった。

で、結局rpmfindを使うことに。yum管理ではなくなるのでちょっと微妙だけど、背に腹は代えられないのでまずはrpm探しをしてみることにした。そしたらありました。

postgis-1.2.1-1.el5.rf.i386.rpm
postgis-utils-1.2.1-1.el5.rf.i386.rpm

とりあえずpostgis本体をインストールしようとしたけどエラー。proj-develというのとgeos-develがないと怒っている。もう後は依存関係を解消すべく、ひたすら検索。そうすると合計4点インストールすることになった。

geos-3.1.0-1.el5.rf.i386.rpm
geos-devel-3.1.0-1.el5.rf.i386.rpm
proj-4.5.0-3.el5.i386.rpm
proj-devel-4.5.0-3.el5.i386.rpm

いちおうインストールを完了し、それからpostgisをインストールしようとコマンド一発！・・・できたぁーっ。rpmfindに感謝。しかしこの時点ではpostgis-utilsがインストールできていない。ユーティリティだから、なくても問題ないとは思うが、ちょっと気になる。

perl(Pg) is needed

と言われているだが、これは何。rpmfindでperl-Pgというのがあるみたいだが、ここにはRedHat用が見当たらないから、インストールしたくない。ということで放置することにする。

さて、これでPostGISが使えるようになったかどうかはわからない。PostgreSQLを初期化してみればわかることだけど、まだPostgreSQLは起動さえしていないからだ。あとでゆっくりチェックしてみることにする。