PostgreSQL Part.11©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
文字コード順でも辞書順でも、それを正解とするかどうかは要件次第。
ちなみに漢数字は、訓読み順で並んでいる。 >>199
理解した。Linuxでも順序は変わるね。
ひらがな／カタカナの濁／半濁の扱いは今でも差があるようだ。設計思想？互換性？
msvcrt: ハはバばパぱ
glibc : はばぱハバパ
環境依存が怖い。要件次第だが、自前で「ふりがな」列を用意したほうがマシだな。 他人に公開する予定の無い、自分専用のwebサイトを作る場合でもSQLインジェクション対策はしておいた方がいいよね？
クラスを転用するときに問題になるし、悪意が無くてもエラーのもとだし >>203
言語によるけど今時パラメータクエリぐらいは使えるだろうから普通にパラメータクエリでやるわな
あとから見てもその方がわかりやすいし >>205
PHPで言えば、pg_query_params()とか？ phpって対策されていないやつ
非推奨じゃなかったっけ
おいらはPDOでやってるかな ぽすとぐれすきゅーえる
ぽすとぐれすえすきゅーえる TIMESTAMP (WITHOUT TIMEZONE)とCURRENT_TIMESTAMPについて教えてください。
INSERTにてCURRENT_TIMESTAMPで入れたあと、SELECTで取り出すと日本時間になっています。
どの時点で日本時間になっているのでしょうか？
1. CURRENT_TIMESTAMPの時点ではJSTだが、INSERTするときにJSTがUTCに変換されて保存され、
SELECTで取り出すときにシステムの時刻を見て+0900されている
2. CURRENT_TIMESTAMPの時点ではJSTで取得されるが、
元々これにタイムゾーンのデータはなく、そのまま保存され、
SELECTで取り出すときは同じシステム時刻を使ってるからたまたま同じタイムゾーンとして取得されている
3. CURRENT_TIMESTAMPの時点ではUTCで取得され、保存もUTCだが
SELECTで取り出すときはシステム時刻を参照して勝手にJSTにしている
4. その他の未知の仕組み >>210
http://www.postgresql.jp/document/current/html/datatype-datetime.html
> 通常timestamp without time zoneの値はtimezoneのローカル時間としてみなされる
とあるから、言葉通りだとするなら：
・INSERTするときに時刻の値だけを保存する (+0900を無視)
・SELECTするときに現在のタイムゾーン扱い (+0900を追加)
SET TIMEZONE TOしながら試してみれば検証できるかも >>210
まず前提として、without time zoneをselectした結果にはtime zone情報はないのだから、UTCもJSTもない。
次にcurrent_timestampは、tz情報付きのデータ。
それをwithout time zone絡むにインサートすると、tz情報は切り捨てられる。（たとえば、"2017-05-12 18:00:00")
そのデータを、日本で取得しようがアメリカで取得しようが、tz情報なしの"2017-05-12 18:00:00"が取得される。
つまり、アメリカで取得した人は、現地時間の"2017-05-12 18:00:00"だと見えるということ。 >>211-212
ありがとうございます。
世界向けのSNSを作ろうとしたのですが、これがネックで
時間部分の設計ができない状態でした。
助かります。 お世話になります。
psql で database ごとに history を分けて表示したい (\s) のですが、
(他の databae の history を表示したくない)
どうやったらいいのでしょうか？
よろしくお願いします。 historyって、homeの .psql_history 出してるだけだからなあ
db切り替えるたびにリネームするとか？ ああ、そういう仕組みなんですね。
複数の database をそれぞれ別々に psql で開いたりしてるんですけど、じゃぁ、全然無理ですね。
わかりました、ありがとうございました。 >>217
そのものズバリですね♪
ありがとうございます。
おかげで、.psqlrc っていう設定ファイルのことも知りました。
PostgreSQL の Documentation にありますね。
かさねがさねありがとうございました。 拡張を使った場合、メジャーバージョンが変わるときのアップグレードで使えなくなったり作業が増えたりするのでしょうか？
スキーマのバージョンが変わっている拡張があったら何かしないといけないとか？ >>221
> 30分単位とかで時間を丸めてくれる関数ないですか
自作すれば？ トリガのデバッグってどうやってますか？
初めてトリガ関数作ります >>224
普通に、クエリ後、関連データを取得してassert >>225
ASSERT文、調べました。
そういうのがあるんですね♪
ありがとうございました >>226
たぶん勘違いしてる
クライアントコードを実装する、JavaとかPHPとかのプログラミング言語で普通にチェックしろってこと
IDEでステップ実行とかできないからね >>227
> クライアントコードを実装する、JavaとかPHPとかのプログラミング言語で普通にチェックしろってこと
そうなの？
それなら俺も勘違いしてたわ。 ASSERTがどうのってのはPL/pgSQLの機能でしょ
https://www.postgresql.jp/document/current/html/plpgsql-errors-and-messages.html
トリガ関数をどの言語で作るかにもよるけど
たいていはサーバーログにメッセージを書き出す、いわゆるprintfデバッグになるのでは そう思う。自立型トランザクションを使えばログ表に対するcommitを必ずしながら
トリガー本来の処理ではrollback等もできる。多分10g以降の機能で9iでは不可。 >>229
普通にデータベースにアクセスするメソッドをテストする方法と同じだよ。
確認する項目が、トリガーが変更したデータも対象になるってだけで。
普通にデータベースにアクセスするメソッドをテストするときもprintfデバッグしてたら、
トリガーのテストもそうなるだろうけど、普通はコードで確認するんじゃないか？ ゴメン。Oracleと勘違いしてた。>>230 は無視して >>231
トリガだと「普通のアクセス」とはデバッグ方法が違いそう、ってのが質問の意図じゃないの？
それを「同じだよ」で済ませるのは会話が噛み合っていない感がある
トリガの内部で何が起きているかのデバッグにはprintf程度しか道具が無いんじゃないかな？
トリガの結果が適切かを確認するにはテストコードを使うのはわかる 日本語メッセージでGSSAPIがGSSAIになっちゃってるところがある >>233
> トリガの内部で何が起きているかのデバッグにはprintf程度しか道具が無いんじゃないかな？
内部が正しいと確信が持てるだけのテストをすればいいだけ。
てか、トリガーのコードじゃなくて、ホストプログラムのコードだってそうだろ？
まぁ、途中で変数の中身を見ないと、なにが行われているのかわかれないスキルレベルだったら話は違うが。 >>235
ホワイトボックステストも知らないなら絡んでくるなよ >>236
いや、ホワイトボックステストの話をしてるつもりだが。
TDDはホワイトボックステストだが、やることは、
・前提条件を作る
・テスト対象のメソッドを呼ぶ
・結果を確認する
を、自分の確証が持てるまでやる。
トリガーをテストする場合も同じ。
トリガーをキックするメソッドを呼び出すか、あるいは直接INSERT/UPDATE/DELETEを実行し、
トリガーが変更した内容を、実際にデータを取得してassertする。
C0カバレッジで満足できるならそこでやめる。
確証が持てないなら、C1カバレッジになるようなテストを追加する。 >>237
テストのやり方はそれでいいけど、テストが失敗してなおかつ原因がよくわからないときの話じゃないかな
そういうときは、raise noticeがやっぱり最強だと思う トリガーはいいとして、複雑なクエリのデバッグはどうやるつもりなんだろうか
それこそ、printfも使えない >>237
背伸びしすぎ
> TDDはホワイトボックステストだが
TDD の話なんて誰もしてない
最近知って話したくてしょうがないのか？ w
そもそも TDD はコードを作る前にテストケースを作るからホワイトボックステストにはならない
むしろ仕様からテストケースを作るのでテストケースの作り方としてはブラックボックステストに近い
> ・前提条件を作る
> ・テスト対象のメソッドを呼ぶ
> ・結果を確認する
その前提条件の作り方の話だぞ
> を、自分の確証が持てるまでやる。
違う、ホワイトボックステストでは内部のコードを考慮してテスト条件を作るんだよ
それがわかってないから
> トリガーをキックするメソッドを呼び出すか、あるいは直接INSERT/UPDATE/DELETEを実行し、
> トリガーが変更した内容を、実際にデータを取得してassertする。
なんてアホなことを言い出す IPAのデータベーススペシャリスト持ってない奴は書き込むなよ デバッグしたいと言ってるやつの目的がわからない。
テストと混同しているみたいでやばそうだな。 >>241
TDDのわかってない奴と議論しても時間の無駄なんで、これでも読んで。
https://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA
> 違う、ホワイトボックステストでは内部のコードを考慮してテスト条件を作るんだよ
C0, C1カバレッジの意味わかってるか？
それを網羅しなければ自信がもてない場合は、それをカバーするテストを納得できるまで追加するんだよ。 >>241
つか、お前、データベースアクセスを含むクラス・メソッドの単体レベルのテストはやってるのか？
やってるとしたら、どうやってんだ？
テストコード書いてるなら、トリガーがあろうとなかろうと関係ないことは自明だろ。 plpgsqlは実行しないとtypoなんかがわからないので、c0必須 >>247
これな
存在しないシンボル名使ってたら、CREATEでエラーにしてくれって話だ raise notice方法の良くないところは、リリース時にそれを削除する必要があること
トリガーをダンプしてバージョン管理とかしてると、ただそれだけでリビジョンが進む
そして、それを忘れやすい データベース内で完結するテスト方法は苦行なんで、
普通にプログラムからクエリを実行してテストしたほうがいいよ >>245
Wikipedia なんて底が浅すぎ w
コードを見てテストケースを作るなんて書いてないだろ？
C0, C1 は結果の話
根本的に理解してないのがバレバレだぞ w
>>246
それトリガーの話じゃないだろ
まあ必死だな、ってだけ言っとくよ w >>252
あ、「クエリを発行して」の言いまちがいね >>253
発行も実行も普通は同じ意味で使われる。 データベースに詳しくないのが、何かの言語と結合してテストするようなのとを言ってるけど、それおかしいから。
データベース軽視なんだろうな。 もともとトリガのテストがしたいという話だが、トリガとトリガが呼び出す関数をいきなり一緒にテストしようとしているのが間違い。
関数は関数でテストして、トリガはトリガがテストして、結合テストはデータのIN/OUTで確認すればいいだけ。
データ観点のテストをあまりしないやつらはかなりいるが、とんでもないから無視した方がいい。 トリガープロシージャって普通の関数として単体で実行できるんだっけ？
やったことないけど、OLDとかNEWとかどう与えるんだろう。 >>257
Oracleのトリガーと混同してたわ。トリガ関数に普通の関数を呼び出すようにしてないとできないな。 >>254
いや全然意味違うけどw
始めて本当に日本語勉強した方がいい人見つけたw >>256
> トリガープロシージャって普通の関数として単体で実行できるんだっけ？
>>237でも言ったが、トリガー関数単体では実行できないので、トリガーのみをテストしたいなら、
INSERT/DELETE/UPDATEを実行して結果を確かめれば良い。
USERSテーブルにINSERTすると、どこかのテーブルのユーザ数合計がトリガーで更新されるとき、
function testUserCountSucc()
{
prevCount = getPrevUserCount();
db->execute("INSERT INTO USERS ...");
currCount = getPrevUserCount();
assertEquals(prevCount + 1, currCount);
}
自分がそのトリガーを実装する場合は、トリガー内のIFやFORがどういう条件でどうなるかは
わかるはずなので、C0カバレッジになるようにテストケースを増やせば良い。
「ユーザを追加するとユーザ数合計が更新される」というのが、ホストコードで実装されるのか
トリガーで実装されるのかを「実装詳細」と考えるなら、実は上のやり方は好ましくない。
Users::Add()をテストするどこかで、ユーザ数合計が更新されているassertionを追加したほうが良い。 s/getPrevUserCount/getUserCount/ なんかもっといろいろ間違ってた。
最初のアンカーは、256じゃなくて>>257
> C0カバレッジ
↓
> C0カバレッジ100% >>256
どういう意味で結合テストっていってるのかしらんけど、単体テストでもデータのIN/OUTで確認するだろ 「発行」するのは人またはプログラム、「実行」するのはRDBMS、という原理主義者なのか？ >>265
そういうことじゃなくて、俺謎理論だと思うよ >>255
DB内で完結するテスト例：http://pgtap.org/
苦行
あえて選ぶなら止めないが >>268
・普通のプログラムでは簡単に書ける「共通処理」が書きづらい
→ まぁ、functionで実装していけばいいが、以下の考慮が必要になる
・テストを変更するのにいちいちmigrationが必要
・テストはテスト対象と同一データベース内におく必要がある
・故に、CIでテストしようとすると全員のテストを一つのDBに入れる必要がある
・そうすると、他人とシンボル名が重複しないようにするなどの配慮が必要だとわかる
・スキーマで分割すればいいじゃんとか思う
・グダる
普通にコードで書くのが楽よ >>269
コードって別の言語だし、ユーザー、スキーマは結合テストレベルでは本番環境に無理に合わせない。
なんでいきなりシステムテストレベルで確認しようとするのか？
まあ小さいパッケージやWebサイト屋だとそういうテストをする会社や人間が存在するのは知っているが。 >>270
ちょっと言ってる意味がわからない。
例えばトリガーを単発でテストする方法は>>261に書いたとおり。
ユニットテストレベルの話をしてるのだが。 >>270
数千人月以上のメガプロジェクトの五次請けさん、お疲れっす pl/pgsqlの、お勧めの入門書ってありますか？
ネットである程度調べられるけど、できれば体系的に学びたいのので >>272
いろいろあなたがずさんなのはいいけど、回答するような立場ではないことは自覚した方がいい。 >>276
>>270の方が回答するレベルでも立場でもないわなぁ
あと、>>270のいうシステムテストレベルって何だよ？ コード書けないし、>>261レベルのコードでも何やってるかわかんなくてぐだぐだいってるんだろ >>279
最近のレスでは、君が一番ピントずれてるよ 結局、どうやってテストするかって>>261以外誰も示せてないな >>279
で、君のところではどうやってテストしてるの？ あれかな、Excelの定型処理を自動化しようとしてマクロ書いたら怒られた的な話？ つか、SIerが仕切る大規模開発で、トリガーが許されるケースなんかあるのか？
トリガーはおろか、ストアドすら許されたことがないんだが。 >>284
そのシステム開発プロジェクトのポリシーだろうけど、理由の一つはプロジェクトメンバーのレベルがあらゆる面で低い、もう一つはデータベースがよくわからなくて上がトリガやストアドファンクションを禁止しているパターン。
こういうそれなりに大きいプロジェクトは総じてクソでうまくいかない。 >>282
データとSQLを用意してトリガーを動かして実行前と実行後を比較する。
なんでこんなあたりまえのことを言われなきゃわからないのか？ >>285
最も大きい理由は、大抵データベース設計チームが独立していて、そこが物理設計まで行い、
パフォーマンスの責任まで負うから。
次に大きい理由は、スキーマの変更手順が決まっていて、製造工程中に変更とか無理だから。
その次は、大抵大きなプロジェクトでは、データベースをデータストアとしてしか使わないから。 >>286
> データとSQLを用意してトリガーを動かして実行前と実行後を比較する。
それマニュアルでやるの大変でしょ？
>>261みたいにテスト書いとけば、CI/CDにも組み込めるよ。
別にマニュアルでやるのは否定しないが、だからといって>>261を否定するのはおかしいよ。 >>286
それ、>>237と同じじゃんw
>>237を否定してたように見えたが、そうじゃないなら何と戦ってるの？ クエリを発行する手段としてホストコードを使うよ、
単体テストレベルの話ならユニットテストツールも使えるよってだけなんだけど、
> 何かの言語と結合して
> コードって別の言語だし
というメンタリティの持ち主なので、話が全然噛み合わない >>290
あなたみたいにこういうのがテストだと思っているから話がおかしくなる。
単にデータベースを使いこなせないことをごまかすために言っているとしか思えない。 PostgreSQLは使われ方から細かいテストをする習慣のない人間が使っていることが多いから理解できないのもわかるよ。 >>291
手動じゃないなら、具体的にどうやってるの？ 手動じゃないならなんらかの方法で結果を自動チェックしてるわけで、>>261と何が違うんだってことになる >>295
それだと結合テストの部類だろ。少なくともPostgresqlなんだからPostgresqlで完結しろよ。 もしかして手動でSQL実行してトリガが自動で動くから自動って言ってるの？ｗ
まさかそんなわけないか >>298
自動テストの「自動」を誤解している。
よくいるのが有名自動テストツールを使用するのが自動テストで、それで確認できるテストだけがテストだと思ってる人間。
画面をポチポチやるのはたしかに手動だが、それ以外は昔からスクリプトでテストする。
あまり自動化しすぎるとテストにならなくなる。すでに完成しているシステムのリグレッションテストなら有効。
リファクタリングもそうだが特定のツールの機能を使うことを指している人間も多い。
話を戻すとここまでpsqlもPL/pgSQLも出てこない。PostgreSQLやMySQLは入門書で他の言語から使うことばかり書かれているから仕方ないとは思う。
データベースはデータの入れ物、SQLはあまりテストしない習慣の人間といくら話しても平行線をたどる。
LAMP環境だとエンタープライズの感覚がわからないひとは多い。 ■ このスレッドは過去ログ倉庫に格納されています
