PostgreSQL Part.5

このエントリーをはてなブックマークに追加
701NAME IS NULL
>>700
フリーズってPC(OS)丸ごと? クライアントアプリだけ?
アクセスしようとしたクライアントはナニ?
postgres以外のアカウントだとどぉう?

っていうか、posgreってなんだよ。
702NAME IS NULL:2008/06/16(月) 09:29:14 ID:???
>>699
別にPostgreSQLで困りはしないだろ。
703NAME IS NULL:2008/06/16(月) 11:34:23 ID:???
>>699
どっちでもいいので、DBは統一しておいた方が楽。
特にこだわりがなければPostgreSQLでいいでしょう。
704NAME IS NULL:2008/06/16(月) 15:32:22 ID:???
705NAME IS NULL:2008/06/16(月) 16:38:53 ID:???
>>704
そうみたい
706NAME IS NULL:2008/06/16(月) 16:40:42 ID:???
>>699
併用しても問題ないけど、管理の手間を考えたらposgres一本の方がいいよ。
キャッシュの割り当てとかも一括だし。運用に携わる人はpostgresもmysqlも
どっちもプロフェッショナルなの?両方混ぜると似たようなコマンドで混乱すると思うんだけど。

あとマスタとか共通利用できないの?できるんだったらマスタテーブル一個の方が
更新も楽だしいいと思うけど。ものすごい負荷の高いシステムで将来的に
DBをわける可能性が大きいなら、今からインスタンスを分けておく意味も
あるかもしれない。
707NAME IS NULL:2008/06/16(月) 23:12:40 ID:???
もし分けるとしても同じDBMSのほうがよさげに思う。
同じシステムのPC版、携帯版という違いであれば同じDBMSにしといたほうがいいよ。
708700:2008/06/16(月) 23:47:37 ID:???
>>701
DOSからアクセスしたのですが、passを入力してenter押すとOSごとフリーズしてしまいます。
709NAME IS NULL:2008/06/16(月) 23:49:20 ID:???
>>708
ローカルマシンのPostgreSQLインスタンスにpsqlで接続しようとしたらOSごとフリーズってことですか?
710699:2008/06/16(月) 23:56:17 ID:???
>>702、703、706、707
みなさん、ありがとうございます。
postgresで統一したいと思います。

PCと携帯で違うデータを見せたいのですが
マスタテーブルも一つにした方が良さそうですね・・・。
ありがとうございました。
711NAME IS NULL:2008/06/17(火) 10:26:27 ID:???
統一にしても、DBクラスタを別にしてPostgreSQLを複数起動するとか、
DBを別にするとか、スキーマでわけるか、テーブルで分けるか、キーで分けるか、
712700:2008/06/17(火) 17:27:59 ID:???
>>709
そうです、ネットで調べた通りにやったのですが無理でした。
713NAME IS NULL:2008/06/17(火) 17:47:13 ID:???
>>712
まずメモリをチェックしなさい。
次にHDDをチェックしなさい。

Linux(Unix)ならこんな事で落ちない。
うんともすんとも言わない。メッセージが出ない。
保護違反とかのエラーは全てメモリエラーと思っていい。
714NAME IS NULL:2008/06/17(火) 18:20:27 ID:???
メモリエラーの結果、誤動作して保護違反ということはあるかもしれないが
保護違反とメモリエラーとは直接の関係は無い。
715NAME IS NULL:2008/06/17(火) 18:25:12 ID:???
保護違反じゃなくて、理由のわからないフリーズはハードを疑ったほうがいいけどな。
フリーズってのが全体が止まるのならな。
716NAME IS NULL:2008/06/17(火) 19:18:07 ID:???
ハードだろうね。
保護違反ならメッセージ出るか再起動するかする
717700:2008/06/18(水) 00:44:28 ID:???
ということは、自分のパソコンを修理に出すべきなんでしょうか?
普通に使っている分には、まずフリーズしないのですが・・・SP1入れようとするとフリーズしますが・・・。
718NAME IS NULL:2008/06/18(水) 01:32:15 ID:???
ノートで熱暴走してるとか

ないか
719NAME IS NULL:2008/06/18(水) 04:34:25 ID:???
>>717
だめじゃん
720NAME IS NULL:2008/06/18(水) 10:21:41 ID:???
アンチウィルスソフトで引っかかってUAEの警告だそうとしてるだけとか

ないか

pgAdminではつなげないの?
721NAME IS NULL:2008/06/19(木) 00:15:18 ID:???
sp1入れてフリーズって普通じゃないよな。
pc新規購入をお勧めする。
722NAME IS NULL:2008/06/19(木) 00:24:28 ID:???
PC買い替える前にOS再インストールだな。
723NAME IS NULL:2008/06/19(木) 01:34:49 ID:???
の前にH/Wいろいろチェック
724NAME IS NULL:2008/06/20(金) 11:25:00 ID:???
Explaining Explain日本語版ドラフト ? NPO法人 日本PostgreSQLユーザ会
http://www.postgresql.jp/blog/56
にある Explaining Explain の日本語版読んでみたいんですが、
パーマリンクの変更があった影響なのか
単にもうファイルがないのか読めないでおります。
どなたかファイル持ってる方いらっしゃればどこかにあげていただけないでしょうか?
JPUG公式ぽいんですが、コメントのSPAM荒れっぷりを見てもメンテされてない可能性があるので
こちらにきてみました。

コリコリにDBチューニングしたいわけではなくて、SQLかく時にある
ちょっとした迷い(結果同じだけどどっちの書き方がいいかな?)
をクリアする助けになればなぁと思ってる感じです。
725NAME IS NULL:2008/06/20(金) 12:05:19 ID:???
726724:2008/06/20(金) 12:59:02 ID:???
ぐぁ・・・基本的なことが抜けておりました。
大感謝です!
727NAME IS NULL:2008/06/28(土) 23:16:56 ID:???
すみません
質問させて下さい。

PostgreSQL Ver 8.3
WindowsServer2003
でDBを運用しているのですが、
現在dataフォルダが初期インストールパスのままになっております。
別ドライブにdataフォルダを移動しようと試みて、
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\pgsql-8.3\ImagePath
を変更してみたのですが、
変更先がCドライブ以下なら変更可
他のドライブは変更不可(サービスが起動しない)
となってしまいます。

この場合、dataフォルダを退避して、PostgreSQLの再インストール
しか方法は無いのでしょうか?
何とかdataフォルダの移動だけで済ませたいと考えております。

アドバイスを宜しくお願いします。
728NAME IS NULL:2008/06/28(土) 23:32:34 ID:???
上げてみました
729NAME IS NULL:2008/06/28(土) 23:45:40 ID:???
うちのWinXPでは実行ファイルはC:にインストールしてあって、
-Dで指定するデータ領域は別のドライブにしているけど、普通に動いてる。
730NAME IS NULL:2008/06/28(土) 23:55:33 ID:???
>>729さん
ありがとうございます。

多分initdb.exeで -D 以降に移動させたいファイルパスを指定
してあげればいいのかなと思うのですが、initdb.exeの使い方が
いまいちわかりません・・・。

新規にデータ領域を作成して、そこに既存のdataフォルダをコピー
するような感じでいけるんでしょうか?

initdb.exeはコマンドプロンプトで実行するのでしょうか?

もしわかれば教えてください。
宜しくお願い致します。
731NAME IS NULL:2008/06/29(日) 00:06:36 ID:???
既存のデータ領域があるなら丸ごとコピーして-Dでそっちを指すようにすれば動くんじゃないかな。
initdb はコマンドプロンプトで --help とかつけて動かせば説明が出るけど、
>>1のドキュメントを読んだ方が良いかも。
732NAME IS NULL:2008/06/29(日) 01:13:30 ID:???
>>731
アドバイスありがとうございます。

取り合えず調べて、空の別ドライブのdataフォルダにinitdbの実行し
成功するまでは出来ました。

その後、新規dataフォルダを既存のdataフォルダに上書きして、
サービスの実行・・・・・・起動不可

再度、空のdataフォルダを作成して、initdbを実行。
今度はそのままサービスの起動・・・・・・起動不可

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\pgsql-8.3\ImagePath
の値はinitdbの指定パスと同じにしているのですが、他に設定
が足らないのでしょうか?
733NAME IS NULL:2008/06/29(日) 01:34:59 ID:???
>>732
コントロールパネル -> コンピュータの管理 -> サービス を開いて
PostgreSQLのプロパティを見て、[全般]タブの「実行ファイルパス」が
レジストリと同じ値になっているか確認して味噌。

っていうか、レジストリを直接弄るってはじめて知った。
scコマンドを使うものばかりだと...。
734NAME IS NULL:2008/06/29(日) 01:37:19 ID:???
システムのログでも見れば。
735NAME IS NULL:2008/06/29(日) 02:05:45 ID:Kc/12zlO
>>733
>>734
ありがとうございます。

>レジストリと同じ値になっているか確認して味噌。
ここは同じになっております。
多分、レジストリの値を参照して、ここに表示しているようですね。

>システムのログでも見れば。
今見てみました。
postgres cannot access the server configuration file "F:/data/postgresql.conf": No such file or directory

とのエラーメッセージを発見しましたが、該当の
F:\data\postgresql.confは存在します。

なぜでしょう?
736NAME IS NULL:2008/06/29(日) 02:28:40 ID:???
>>735
元Unix系でWindowsに移植されると、あるのにNo such file... って出て悩ませるときがあるよねぇ。
ユーザpostgresに読み取りアクセス権限が設定されていないとか。
そんときゃpostgresql.confだけじゃなくて、/dateディレクトリ下の全てのファイルとディレクトリを
設定し直さなきゃだが?
737NAME IS NULL:2008/06/29(日) 11:49:56 ID:???
psql (PostgreSQL) 8.2.4 を使ってますが、バックアップとリストアをしようとしています。
pg_dumpallでファイルにバックアップした後リストアすると文字化けが発生してしまいます。
登録データーがSJISなのですが、OSはUTF-8 CJKになってる為と思われますが文字化けを回避する方法はありますでしょうか。
また、上記状態でpg_dumpallしてあるファイルを文字化け無しにリストアする事は出来ないでしょうか。
宜しくおねがいします。
738NAME IS NULL:2008/06/29(日) 11:55:18 ID:???
つ nkf

バックアップ前・後のDBの文字コードは同じ?
FTPとかを利用してファイル移動とかする際に
文字化けが入ってしまう可能性は無い?
使用しているOSは?

もうちょっと情報プリーズ
739737:2008/06/29(日) 12:21:50 ID:???
>>738

早速のご回答、ありがとうございます。
バックアップ前・後のDBの文字コードは同じです。
postgresはfedora上で動いており、XPからwinSCPとputtyを使ってアクセスしてますが
バックアップしておいた時点のDBを再現したいので最悪はputtyでログインして
fedoraのディスクにそのままバックアップとリストアが出来れば良いです。
出来ればwinscpでローカルのXPにバックアップ出来れば嬉しいですが…

nkf、ググって見ました。pg_dumpallしてしまったファイルに適用しても元に戻せるのでしょうか。ちょっとやってみます。
740NAME IS NULL:2008/06/29(日) 12:24:11 ID:???
>>738
>FTPとかを利用してファイル移動とかする際に
>文字化けが入ってしまう可能性は無い?

記憶が曖昧なのですが、fedora上でputtyでログインし
バックアップとリストアしても文字化けした様に思います。
741NAME IS NULL:2008/06/29(日) 12:34:07 ID:???
× 記憶が曖昧なのですが、fedora上でputtyでログインし
○ 記憶が曖昧なのですが、fedoraにputtyでログインし
742NAME IS NULL:2008/06/29(日) 13:06:59 ID:???
>> 737
そもそもDB作るときに文字コード何にした?

$ psql -U postgres -l
List of databases
Name | Owner | Encoding
------------------+-----------+----------
***** | ******** | UTF8

この一番右のEncodingの値
743NAME IS NULL:2008/06/29(日) 13:21:10 ID:???
>>742

-bash-3.2$ psql -U postgres -l
List of databases
Name | Owner | Encoding
-----------+----------+-----------
postgres | postgres | UTF8
template0 | postgres | UTF8
template1 | postgres | UTF8
test | postgres | EUC_JP
test1 | postgres | SQL_ASCII
(5 rows)

となってます。test1が目的のDBなのでSQL_ASCIIで良いでしょうか。
744NAME IS NULL:2008/06/29(日) 13:42:39 ID:???
>>743
テストしてみた

test1が元データだよな?

## 吸出し部分
# DB作成
createdb -U postgres -E SQL_ASCII test2

# test2にSJISデータを流し込む(手動)

# データ吸出し
pg_dump -U postgres test2 > test2.sql

# SJISからUTFに変更
cat test2.sql |nkf --ic=sjis -w > test2.sql.utf

# ここでFedora上で読めるようにUTFに変換されている
# winscpでwindowsに転送してみた
test2.sql => SJIS
test2.sql.utf => UTF8
の文字コードであることを確認

# 戻すテスト
createdb -U postgres -E SQL_ASCII test4
cat test2.sql.utf |nkf -s |psql -U postgres test4

これで無事に戻せた。

特に問題なさそうだが、何処でダメなんだ?
745NAME IS NULL:2008/06/29(日) 14:38:36 ID:???
>>744
実験までして頂いてお手数掛けます。

>test1が元データだよな?
そうです。pg_dumpは部分的ににかバックアップしない様なので使ったことが無いのですが

pg_dumpall > backup.sql
とした時にbackup.sqlが既に壊れているのでは無いかと考えていて
今、実験中なのですが自信が無いです。

単純に
pg_dumpall > backup.sql
psql -f backup.sql
とした時に標準出力(linuxのUTF)で化ける事って無いのでしょうか。
backup.sqlはUTFに変換されてしまいますよね。
それとも、実験して頂いた手順に
># SJISからUTFに変更
とあるのでSJISのままなのでしょうか。
746NAME IS NULL:2008/06/29(日) 14:52:45 ID:???
>>745
とりあえずbackup.sqlの文字コードを調べてみ。

こんなかんじで。

$ nkf --guess test2.sql
Shift_JIS
$ nkf --guess test2.sql.utf
UTF-8

ここまで書いて思ったんだが

test | postgres | EUC_JP
test1 | postgres | SQL_ASCII

ってことはEUC_JPのやつとSJISのデータを混ぜて出力してる?
747NAME IS NULL:2008/06/29(日) 16:55:09 ID:???
>>746
やってみました

-bash-3.2$ nkf --guess backup.sql
BINARY

でした。

ちなみにbackup.sqlの先頭の方で

SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET escape_string_warning = 'off';
 | |
REVOKE ALL ON DATABASE template1 FROM PUBLIC;
REVOKE ALL ON DATABASE template1 FROM postgres;
GRANT ALL ON DATABASE template1 TO postgres;
DROP DATABASE test;
CREATE DATABASE test WITH TEMPLATE = template0 OWNER = postgres ENCODING = 'EUC_JP';
DROP DATABASE test1;
CREATE DATABASE test1 WITH TEMPLATE = template0 OWNER = postgres ENCODING = 'SQL_ASCII';

となっていてエラーも出ていない様なのですが、多種類の文字コードだと出力出来ないのでしょうか。



backup.sqlの容量が900Mバイトもある為かサーバの反応が遅すぎるので、テスト用のサーバーを買ってこようと思います。
748NAME IS NULL:2008/06/29(日) 17:45:07 ID:???
>>747
>多種類の文字コードだと出力出来ないのでしょうか。
DBごとにdumpしてみたらどうなのさ? もうちょと自分で思考錯誤しる。
749NAME IS NULL:2008/06/29(日) 19:03:19 ID:???
もしかして: 試行錯誤
750737:2008/06/30(月) 07:50:38 ID:???
>>748

DB毎にdumpしてみましたが文字化けが発生している様でした。
別サーバーを立てて文字化け部分を切り出そうとしている所ですが
昨日の初書き込みから、お蔭様でだいぶ進展した感じです。
暫く自分でやって見てまた判らない事がありましたら質問させて頂きます。
本当にありがとうございました。
751NAME IS NULL:2008/06/30(月) 16:37:15 ID:???
環境変数のPGCLIENTENCODINGとか?
752NAME IS NULL:2008/06/30(月) 16:40:40 ID:???
DB毎に文字化けってどういうこと?
例えばEUC_JPで出したものをEUC_JPとして見ようとしても化けてるの?

文字化けしてると勘違いしてるだけじゃね?
753NAME IS NULL:2008/06/30(月) 18:37:06 ID:???
DBをASCIIでつくっちゃったんならクライアントの
文字列をそのままバイト配列として格納してくれるんだっけ?

新しいDBをUTFで作ってプログラム組んでSELECT->INSERTしたほうが
早そうだけなあ
754NAME IS NULL:2008/06/30(月) 23:38:49 ID:???
現在レンタルサーバを借りているのですが、データベースのバックアップをしようと思い、pg_dumpをした所「WARNING: ignoring unconvertible UTF-8 character」と言ったメッセージが表示されました。
ただ一応ダンプデータは作られたので、そのデータを元に復旧を試みた所、一部データが欠落していました。

ググッてみて文字変換の問題のような気がしたのですが、ユーザーレベルで解決する方法が分かりませんでした。
ttp://www.google.com/search?num=50&hl=ja&lr=lang_ja&q=WARNING:+ignoring+unconvertible+UTF-8+character&revid=994610375&sa=X&oi=revisions_inline&resnum=0&ct=broad-revision&cd=1

その為何か良い手ががございましたら、アドバイスをいただければと思います。
よろしくお願いします。
755NAME IS NULL:2008/07/01(火) 02:01:50 ID:???
>>754
DBがUTF-8でシェルのLANGがUTF-8じゃないとかじゃないの?
繰り返しになるけど、
環境変数のPGCLIENTENCODINGとか?
756NAME IS NULL:2008/07/01(火) 15:37:39 ID:???
PostgreSQLって基幹業務でも安心して使えますか?
757NAME IS NULL:2008/07/01(火) 16:10:24 ID:???
>>756
管理者が詳しければ安心
管理者が詳しくなければどのRDBMS使っても安心できない。
758NAME IS NULL:2008/07/01(火) 16:14:23 ID:???
DB本体はともかく、基幹業務となるとバックアップとレプリケーションかなぁ。
一番の問題はPostgreSQLを扱えるSIの質と数だろうけど。
759NAME IS NULL:2008/07/01(火) 16:30:12 ID:???
1万ユーザーで同時使用は1000人くらいですが
パフォーマンス的には問題ないでしょうか?
760NAME IS NULL:2008/07/01(火) 16:37:14 ID:???
使用状況や環境にもよるでしょ。
761NAME IS NULL:2008/07/01(火) 16:43:03 ID:???
具体的なトランザクション数とまでは言わないけれど、一口に同時使用が
1000人といっても、それはフロント部分の作りに大きく依存するでそ。
それだけじゃなんとも言えない罠。ただ、今現在そのシステムがOracle等で
動いているのなら、パフォーマンス的にはPostgreSQLでも動くはず
というのはいえる。
762NAME IS NULL:2008/07/01(火) 23:30:29 ID:???
>>755
ありがとうございます。
確認した所下記のようになっておりましたorz。
LANG=ja_JP.eucJP
PGCLIENTENCODING=EUC_JP

現時点でレンタルサーバの設定は触れないので、
自分で似たような環境を作り試してみた所、
UTFからEUCに変換できない文字(?など)があると現象が発生するような感じでした。

多分データベースがUTF-8なのに対し、PGCLIENTENCODINGがEUC_JPの為、
pg_dump時にEUC_JPにコンバートしてしまい、EUCに変換できない箇所でWarningが出ているのかなと思いました。
なおLANGは無関係そうな感じでした。

その為、PGCLIENTENCODINGの設定を変更してもらう方向で検討してみたいと思います。
どうもありがとうございました。
763NAME IS NULL:2008/07/01(火) 23:34:10 ID:???
>>762の上から8行目は文字コード0xE28094のUTFの文字を貼り付けたのですが、文字化けしてしまいました。
多分pg_dumpでも同じようなことがおきてWARNING表示になったのだと思います。
764NAME IS NULL:2008/07/01(火) 23:53:51 ID:???
>>762
自分の環境変数は自分で変えられるよ
export PGCLIENTENCODING=UTF-8
ってやってからpg_dumpしよう
765NAME IS NULL:2008/07/01(火) 23:58:16 ID:???
連投ごめんです。
記憶違いでなければ、PGCLIENTENCODINGが設定されていない場合はLANGが使用されたと思うよ。

んで、ダンプファイルを突っ込むときにエンコード周りのエラーが出た場合なんだけど、
ダンプファイルの中の set client_encoding という行がある場合はそれが
優先されているので、そこがおかしくないかチェックしてみるとよいです。
766NAME IS NULL:2008/07/02(水) 00:15:01 ID:???
>>764
レスどうもです。
一応自分で構築したサーバーで>>764の記述と
export PGCLIENTENCODING=EUC_JP
でのpg_dumpの出力結果を元に>>762のような感じかなと推測しました。

実際に使用しているレンタルサーバーの方は、
自分の判断だけでは手がつけられないため、試してないですが。

>>765
私の構築したサーバーの設定は下記ですが、問題なかったのはLANGにUTF-8を指定してたからということですね。
LANG=ja_JP.UTF-8
PGCLIENTENCODINGはなし

危うく、PGCLIENTENCODINGの設定を無くすだけで終えるところでした。
データベースは複数ありますがどれもUTF-8なので、PGCLIENTENCODINGをUTF-8にする方向で対応したいと思います。

後、手元に問題のダンプデータがないので、明日Warningのでる場合と出ない場合のset client_encodingの記述をチェックしてみます。
どうもありがとうございました。
767NAME IS NULL:2008/07/02(水) 09:25:32 ID:???
pg_dumpに-eって無かったっけ?
768NAME IS NULL:2008/07/02(水) 10:01:57 ID:???
-E または, --encoding= でしょ、あるよ。
769737:2008/07/02(水) 11:28:22 ID:???
>>751
今回は関係なかった様です。ありがとうございました。

>>752
EUC_JPのDBは化けてませんでした。
と言うか、SQL_ASCIIのDBを削除する為に仮に作っただけだったので、データーが殆ど入ってなかったと言うのもありますが。


追伸
SJISの文字化けで質問していた者です。他の業務が入ってしまい追試が遅くなりました。
色々やってみましたが、DBから携帯からのメールのみ削除してバックアップした所文字化けがなくなりました。
携帯の特殊文字に関連しているのかも知れません。とりあえずプログラマにその旨を伝え、対応してもらう事になりました。
時間が取れたらこちらでも詳しく調べようと思います。
ご教示頂いた皆様、本当にありがとうございました。

追伸2
4GのメモリとQuadのマザー買っちゃいました。素人が試行錯誤するには反応が早くて良いですね。
770NAME IS NULL:2008/07/02(水) 21:56:28 ID:???
>>765
set client_encodingチェックしました。
すべてのダンプがEUCでしたorz
どうもありがとうございました。

それと、私が試した限りではPGCLIENTENCODINGが設定されていない場合、
LANGではなく、データベースのEncodingが使用されているようでした。
その為、下記のaaaaというデータベースのダンプはEUC_JPで作られ、
bbbbというデータベースはUNICODEで作られていました。

 List of databases
Name|Owner|Encoding
-----+-----+--------
aaaa |ccccc |EUC_JP
bbbb |ddddd |UNICODE


>>767>>768
使用しているバージョンが7.4.19なのですが、このバージョンでは-Eと--encoding=はないようです
(pg_dump --helpで調べましたが、そのオプションは存在せず、試してみてもエラーになりました)。
出来れば既存の環境には手を加えたくないので、PGCLIENTENCODINGには手をつけず、
pg_dump -Eで対応できれば良かったのですが。
何か良い案があるようでしたらアドバイスいただければと思います。
今はまだPGCLIENTENCODINGを変更すると、既存の環境に悪影響が出ないか検証できていない為、
変更できていないので。

なおpg_dumpのマニュアルは下記を参考にしました。
ttp://www.postgresql.jp/document/pg812doc/html/app-pgdump.html
ttp://www.postgresql.jp/document/pg746doc/html/app-pgdump.html
771NAME IS NULL:2008/07/02(水) 23:37:35 ID:???
>>765
PGCLIENTENCODINGが設定されてない場合の補足ですが、
下記のサイトに以下の記載がありました。

> -E encoding
> --encoding=encoding
> 指定した文字セット符号化方式でダンプを作成します。デフォルトでは、ダンプはデータベースの符号化方式で作成されます
> (PGCLIENTENCODING環境変数を好みのダンプ時の符号化方式に設定することで、同じ結果を得ることができます)。
ttp://www.postgresql.jp/document/pg812doc/html/app-pgdump.html

この文章の「デフォルトでは、ダンプはデータベースの符号化方式で作成されます」というのが、
>>770のEncodingの部分を指していると思われます。
772NAME IS NULL:2008/07/03(木) 02:08:24 ID:???
テーブルに登録している「folderpath」を
SQLのWHERE句にて
Like検索したいのですが、
以下結果となりました。


1. folderPath = "c:\\test" OK (データ取得成功)参考
2. folderPath like "c:%" OK
3. folderPath like "c:\%" OK
4. folderPath like "c:\\%" NG (取得データ0件)
5. folderPath like "c:\t%" NG
6. folderPath like "c:\\t%" NG


\が入っているフォルダパスを
検索する良い方法はないですか。

よろしくお願いします。
773NAME IS NULL:2008/07/03(木) 03:31:45 ID:???
>>772
フロントエンド(psqlなりプログラミング言語なり)がエスケープする分とlikeがエスケープする分が必要。

folderPath like 'c:\\\\%'
774NAME IS NULL:2008/07/03(木) 09:53:15 ID:???
c:\% がOKなのは、 c:\% → c:% → c:% だからだな。
775NAME IS NULL:2008/07/04(金) 14:49:20 ID:gyCCSjbu
MYSQLからPostgreSQLに乗り換えたいと思いインストールしてみたんですが
phppgadminから起動が出来ません

環境は
apache2.2/PHP5/PostgreSQL8/WindowsXP
php.iniの php_pgsql.dllの部分の;は解除してますが
phpinfoにもPostgresが出てきません
インストールが失敗しているんでしょうか?
一応 ユーザーアカウントを新しくrootとして権限をかけて作りました
Linux環境のサイトが多くWindowsの情報が無く困ってます

Phppgadminのエラー詳細は
データベースをサポートするように
PHP のコンパイル・インストールがされていません。
configure の --with-pgsql
オプションを用いて PHP を再コンパイルする必要があります。
776NAME IS NULL:2008/07/04(金) 15:43:53 ID:???
phpinfoに出てこないんじゃ、そもそも無理でしょ。
PostgreSQLが使えるようにビルドしなおすか、
ビルドしたバイナリ持ってくるしかない。
777776:2008/07/04(金) 15:49:51 ID:???
ちょっとググってみたけど、extension_dirは設定してる?
そして、extension_dir にちゃんと php_pgsql.dll は入ってる?
778NAME IS NULL:2008/07/04(金) 16:09:43 ID:???
>>775
phpinfo();
でpgsqlのセクションが表示されなければ
たぶん、extensions_dirの設定ミス。

つか、Win32版のバイナリなら再コンパイルとか不要で、
ほとんどのオプションはphp.iniの設定変更のみで使用できる。
779NAME IS NULL:2008/07/04(金) 18:49:06 ID:???
>>775
Bug #44905 PHP 5.2.6 fails to load PostgreSQL related libraries 
http://bugs.php.net/bug.php?id=44905

これかな?
780NAME IS NULL:2008/07/05(土) 20:29:39 ID:???
>>775
Windowsなら大人しくxampp使っておけ
http://www.apachefriends.org/jp/xampp-windows.html
MySQLとかゴミが一緒に入るけど起動しなければ無害
そしてPostgreSQLは別途インストール
781NAME IS NULL:2008/07/09(水) 09:40:20 ID:???
プライマリキーのフィールドってインデックス化されるんだったけ?
それとも別途CREATE INDEXしなくちゃいけないの?
他のDBとごっちゃになってきた
782NAME IS NULL:2008/07/09(水) 11:05:17 ID:???
プライマリキーを設定するとユニークなインデックスを作成します。
つか設定したときメッセージ出るべ?
783NAME IS NULL:2008/07/09(水) 11:26:51 ID:???
>>782
サンクス
メッセージはC#&Npgsqlで直接CREATE TABLE&CREATE INDEXしてたもので出なかったのよ
784NAME IS NULL:2008/07/09(水) 11:49:02 ID:???
>>783
調べる基本はドキュメントでしょ。
http://www.postgresql.jp/document/pg833doc/html/sql-createtable.html
の「注釈」を読みましょう。
785NAME IS NULL:2008/07/09(水) 15:23:31 ID:???
>>775
PATH設定してみては?
おれもそれっぽいのにぶつかったが、>>777の内容はクリアできてても
phpinfoでは出てこんかった。
とりあえず、PostgreSQLのbinにPATH通したら出てきたよ。

>>779の中にも同じような対処法も書いてある。
(PostgreSQLかPHPのインストーラーでうまくやれよ…と思うんだけど)
786NAME IS NULL:2008/07/09(水) 15:44:52 ID:???
textのフィールドを範囲検索かつあいまい検索できるのでしょうか?

仮にtextのフィールド名をmojiretuとして
データが
AAA0001
AAA0002
AAA0003
BBB0001
BBB0002
BBB0003
とあった場合

あいまい検索は
select * from testTable where mojiretu like '%0001'

範囲検索は
select * from testTable where mojiretu >= 'AAA0001' and mojiretu <= 'AAA0002'

これで
AAA0001
AAA0002
BBB0001
BBB0002
だけを引っ張るにはどういうSQL文になるのでしょうか?
787NAME IS NULL:2008/07/09(水) 17:44:12 ID:???
or 使えよ
788NAME IS NULL:2008/07/09(水) 18:16:49 ID:???
正規表現で
SELECT * FROM testTable WHERE mojiretu ~ '.*000[1-2]'
とか。
789NAME IS NULL:2008/07/09(水) 21:11:13 ID:???
LIKEを「あいまい検索」ってのは初めて聞いた。
790NAME IS NULL:2008/07/09(水) 23:22:13 ID:???
俺の知り合いにも完全一致じゃないのを「あいまい検索」って言うのがいる。
面倒だからいちいち突っ込まない。
791NAME IS NULL:2008/07/09(水) 23:56:57 ID:???
>>789
部分一致をあいまい検索と呼ぶのは、そう呼ぶ客が少なからずいるから、気持ちはわからんでもないのだけど、
>>786の例だと後方一致なんだよなw
792NAME IS NULL:2008/07/10(木) 02:02:04 ID:???
テーブル内容が同一の2つのDBがあるのですが、SQLコマンド
一発でDB1のデータをDB2と同一にするような方法はあるもの
でしょうか。

ご教示いただけますと幸いです。
793NAME IS NULL:2008/07/10(木) 07:46:45 ID:???
LIKE あいまい検索 の検索結果 約 6,370 件中 1 - 10 件目 (0.20 秒)
794NAME IS NULL:2008/07/10(木) 09:38:19 ID:???
>>792
ありません。
レプリケーションの機能は現在のPostgreSQLの弱点の一つです。
795NAME IS NULL:2008/07/10(木) 09:38:50 ID:???
って同じにするだけならdumpしてrestoreすればいいけどな
796NAME IS NULL:2008/07/10(木) 09:45:59 ID:???
>>795
それだ!
797NAME IS NULL:2008/07/10(木) 10:03:10 ID:???
>>788
postgres って正規表現一致使えたのか・・・
永らくそれっぽい検索とかに展開して激しく無駄なことしてたよ・・・
吊ってくる
798NAME IS NULL:2008/07/10(木) 14:16:46 ID:???
>>787,788
試してみます、サンクス

>>789-791
お客さんには伝わりやすいのですが
このスレの先輩方のおかげで正式名称がわかりました
799NAME IS NULL:2008/07/10(木) 14:27:45 ID:???
俺的にはあいまい検索って言ったら表記の揺れを考慮するやつ。
800NAME IS NULL:2008/07/10(木) 16:16:31 ID:???
あいまい三センチ