PostgreSQL Part.5 - 暇つぶし2ch

PostgreSQL Part.5 at DB

1:NAME IS NULL
07/12/01 21:38:37 LPSUO/OT
PostgreSQL (ぽすとぐれすきゅーえる, ぽすとぐれす) について語るスレです。
前スレ [【Windows】 PostgreSQL8　Part.1 【対応】] ｽﾚﾘﾝｸ(db板)

● 関連サイト
[PostgreSQL 本家] URLﾘﾝｸ(www.postgresql.org)
[日本PostgreSQLユーザ会] URLﾘﾝｸ(www.postgresql.jp)
[ドキュメント] URLﾘﾝｸ(www.postgresql.jp)
[ダウンロード] URLﾘﾝｸ(www.postgresql.jp)
[pgFoundry] URLﾘﾝｸ(pgfoundry.org)

● 関連スレ
[2ch検索] URLﾘﾝｸ(find.2ch.net)
[WebProg/PostgreSQL 2テーブル目] ｽﾚﾘﾝｸ(php板)

2:NAME IS NULL
07/12/02 00:41:47 Q5JHapW8
>>1
乙！　盛り上がっていきましょうw

3:NAME IS NULL
07/12/02 13:35:21
もうpostgresSQLが入ってるサーバを全部ぶっ壊したい

4:NAME IS NULL
07/12/04 02:25:53
ネタがないので、PostgreSQL関連の過去ログでもはっとく。

【Windows】 PostgreSQL8　Part.1 【対応】ｽﾚﾘﾝｸ(db板)
■　　　PostgreSQLのことならここで聞け　　　■ ｽﾚﾘﾝｸ(db板)
■　　　PostgreSQLのことならここで聞け　　　■ ｽﾚﾘﾝｸ(db板)
PostgresSQLについて語ろうｽﾚﾘﾝｸ(db板)
PostgreSQLについて語ろう where OID=2::oid ｽﾚﾘﾝｸ(db板)
PostgreSQL 2テーブル目ｽﾚﾘﾝｸ(db板)
PostgreSQL ＆ pgsql-jp ML 3テーブル目ｽﾚﾘﾝｸ(db板)

5:NAME IS NULL
07/12/04 02:34:18
「ネタがない」と書いて思い出したんだけど、8.3の正式リリースはいつかな?
年明けにでもPCを入れ替えるものがあるので、どうせなら8.3をつっこんでやろうかと思ったり。

6:NAME IS NULL
07/12/04 09:38:05
>>5
今月とか来月じゃなかったっけ？
セミナーでベータ版使ってくれって言ってた。

7:NAME IS NULL
07/12/05 00:41:02 gLh1+dWI
1月だね
本家のMLに流れてた

8:5
07/12/05 00:53:45
>>6-7
サンクス。
初夏の頃にフリーズされてから結構かかったような。
こんなもんでしたっけ? 当初夏から秋にかけてリリースする
雰囲気だったような気もするのだが。

-- 素直に8.2を入れて頃合いを見て8.3へ上げることにすっかな。

9:NAME IS NULL
07/12/05 10:55:20
1月リリース予定のミニプロジェクトの開発で8.3beta使ってる。
初めて使うもので (MySQL からの移行)、せっかくだから Auto VACUUM あったら楽そうでいいかなとか。

Beta 4 の文字列が公式サイトで見られるけど、配布されているもののファイル名は beta3 だね…。

10:NAME IS NULL
07/12/05 11:05:25
AUTO VACUUMは8.1からあるべ

11:NAME IS NULL
07/12/06 09:01:33 symOClnh
beta4やっとで配布サイトに入ったな

12:NAME IS NULL
07/12/07 15:31:14 rx0IPmKF
CentOS5でphpPgAdminをrpmでインストールしようとしています。

URLﾘﾝｸ(phppgadmin.sourceforge.net)
↑のページの中断にRHEL用のrpmの置き場として、
↓へのリンクがあるのですが、NotFoundになっています。
URLﾘﾝｸ(ftp.icdevgroup.org)

どなたか他の置き場などご存知ないですか？？

13:NAME IS NULL
07/12/08 09:29:08
DB使用中の一覧は以下のSQLで見られるようですが、
select * from pg_stat_activity
その接続を強制切断（強制終了）はできるのでしょうか？
Windows版使用です。

14:NAME IS NULL
07/12/09 03:54:35 Pkpabdth
>>8
9.0とメジャーバージョンアップしてもいいぐらい
機能がてんこ盛りだからね。
レビューに時間がかかったみたい。

15:NAME IS NULL
07/12/09 04:05:49
ポスグレと怪獣フェドラはどんどん成長してしまって、
もうわかりませんわ。

16:NAME IS NULL
07/12/10 16:40:19
>>13
procpid でプロセスを終了させるといいようですが、
自分自身の接続のpostgres.exe の PID（procpid）を取得する方法はあるのでしょうか？

17:NAME IS NULL
07/12/12 08:49:31
>>16
つpg_cancel_backend()

18:NAME IS NULL
07/12/13 01:33:25 w5o1YGhv
>>17
16が知りたいのは自分自身のPIDを取得する方法

19:NAME IS NULL
07/12/13 12:04:20
>>18 のレスの意味がよくわからなかったので>>17のpg_cancel_backend調べたら
引数にpidいるのかｗ
\df でそれらしいの探したら pg_backend_pid() というやつで返ってきたけど。

20:NAME IS NULL
07/12/13 14:05:41
>>17-19
ありがとうございます。

select pg_backend_pid();
で自分自身の接続のpostgres.exe の PID（procpid）を取得できますね。
URLﾘﾝｸ(www.fiberbit.net)

select pg_cancel_backend(引数procpid);
で"t"（trueのこと?)が返ってくるけど、プロセスがKILLされるわけじゃないようだし。。。

pg_cancel_backend(引数procpid) の使い方がよくわからないけど、ま、いっか。（＾＾；

21:NAME IS NULL
07/12/13 14:11:46
pg_cancel_backend(引数procpid)
って、たぶん実行中だとキャンセルされるっていう意味なんだろーなー？！（想像）

22:NAME IS NULL
07/12/13 23:18:36 NFig6uWq
誰かプロの方、おしえていただけませんでしょうか。

テーブルの列には、改行コード(\n)を含む文字列が格納されています。
db=# insert into testtable values('123\n456\n789');
db=# select * from testtable;
value
-------------
123
456
789

そこで、上記のように改行された状態ではなく、以下のように
改行コードが\nのままの値でデータベースに入力したいのです。。。
db=# select * from testtable;
value
---------------
123\n456\n789

このようにするには、どのようにinsertすれば良いのでしょうか。。。
すいませんが、よろしくお願いしますm(__)m

23:NAME IS NULL
07/12/13 23:32:12
>>22
> 改行コードが\nのままの値
改行コードが含まれているんだから、表示すると改行されるのが当たり前。

「改行コードを『'\n'という文字列に変換』して」ということなら、
INSERT INTO Table VALUES(replace('123\n456\n789','\n','\\n'));
なんかでやればいいけど、それはもう改行コードじゃなく'\n'という文字列。

24:NAME IS NULL
07/12/13 23:33:24
>>22
URLﾘﾝｸ(www.postgresql.jp)
の4.1.2.1.

25:22
07/12/14 00:19:03 74gC5soq
>>23
>>24
どうもありがとうございます。
ちょっと試してみます。

26:NAME IS NULL
07/12/14 00:52:16
>>20
pg_cancel_backend()は実行中のSQLをキャンセルする関数。
プロセスを終了させるもんではないわな。
例えば、数分間結果が返ってこないSQLを一旦キャンセルしたいようなときに使う。

27:NAME IS NULL
07/12/14 02:15:50
>>26
やはりそうでしたか。
どうもです。
pg_kill_pid()なんていう関数があると便利なんですがねぇ。笑

28:NAME IS NULL
07/12/14 04:16:14
バカって悪用される可能性を考えないんだよな。

29:NAME IS NULL
07/12/14 05:05:24
プロセス切られることによって、それから悪用される可能性ってあるかなぁ？

30:NAME IS NULL
07/12/14 05:17:17
もっとバカはね、
postgres.exe 以外のプロセスもKILLできると勘違いしてるか、
プログラミングができない人だよ。
仮にKILLできても、su や admin なら問題ない。

31:NAME IS NULL
07/12/14 05:25:16
次の一手は、
『釣られてるよ』
ですかね？！

32:28
07/12/14 15:27:56
うえへへへへ、まったくバカだぜこいつ……orz
接続毎にバックエンドが上がるのを完全に忘れてた。

危険な機能には権限で対処てのは当然思ってたけど、
pg_cancel_backend(pid)も管理者権限がないと使えないんだな。
PQcancelと違って任意のバックエンドに対して使えるみたいだから
当然だけど。

13が意図してることはさっぱり理解も同意もできないし、
単に接続終了かキャンセル＋終了でよさそうなもんだけど、
調べてみるとpg_terminate_backend(pid)てのがソースにあった。
中身はSIGTERM送るだけ。
信頼性を損ねるからダメとコメントが付いてて使えないが。

長文スマソ

33:NAME IS NULL
07/12/14 17:05:37
プロセスの強制終了できないみたいね。
APIで強制終了できるのかな？

34:NAME IS NULL
07/12/14 17:17:27
>>32
＞単に接続終了かキャンセル＋終了でよさそうなもんだけど、

それってどういうコマンドですか？
その操作でプロセスも終了するんですか？

35:NAME IS NULL
07/12/14 17:23:54
32って反省文ですかね？

>>28
ちなみに悪用される危険性、わからないな。
悪用される危険性があるなら、されないように
関数を作ればいいんではないか？

36:NAME IS NULL
07/12/14 17:28:39
Linuxでは、該当のプロセス、KILLできますか？

37:NAME IS NULL
07/12/14 17:58:17
サービスの停止、最開始が手っ取り早そう。
なんの権限無しにできるのが、アレだけど。笑

悪用もへったくれもないが、さて、どんな風にからんでくるの？

38:NAME IS NULL
07/12/14 17:59:07
>>37
×最開始
○再開始

39:NAME IS NULL
07/12/14 18:03:27
>>37
Windowsの管理者権限だけが必要だね

40:NAME IS NULL
07/12/15 08:20:17
「今から HOGE.HOUR 時間前」ってどう書けばいいですか?

CURRENT_TIMESTAMP - INTERVAL (HOGE.HOUR || ' hour')

と書いてみたが HOGE.HOUR で構文ネラーで撥ねられた。

41:NAME IS NULL
07/12/15 10:02:09
CURRENT_TIMESTAMP - CAST(HOGE.HOUR || ' hour' AS INTERVAL)
CURRENT_TIMESTAMP - (HOGE.HOUR || ' hour')::INTERVAL

42:NAME IS NULL
07/12/15 10:10:07
おお、でけた。
INTERVAL って前置演算子みたいなものかと思ってましたが、よく考えたら型でしたね。
ありがとうございました。

43:NAME IS NULL
07/12/15 16:02:06
PostgreSQL の INHERIT (テーブル定義) って中では内部結合でやってるんですか?

44:NAME IS NULL
07/12/15 21:07:52
Vistaに8.2.5が入らないと思ってたら、以下のページを見つけたのですが、
8.3ではインストーラの方でVista対応してくれるんでしょか？
URLﾘﾝｸ(www.iwahrt.com)

45:NAME IS NULL
07/12/17 08:59:44 VmIYEZ1r
postgresql(linux版)を自分のノートパソコンにいれて使ってます。
某国の株価データを入れているのですが、レコードが7000万件くらいに
なってしまいます。(今はずーっとinsertしつづけていて、5000万件を
越えたところ)。まだ全部入ってないので途中なのですが、
SELECT * from stock_data;
とすると、20分ほど頑張った後でメモリ不足で表示がされませんでした。
一件のレコードは、35個のデータから構成されてます。こういう状況で
上記のSQLとかがサクサク実行できるような方法はありませんか？
メモリは2GB積んでます。
今週終わりくらいに時間がとれるので、oracleとmysqlもためしてみようと
思ってるんですが、mysqlはさわったことないし、oracleはGUI経由
で操作するのを強制されるようなところが嫌で、、psqlとかでリモートから
色々できるのがいいので、できればpostgresqlでやりたいんですが。。
あと、ティックデータも入手できれば飛躍的にデータ量が増えそうなのですが、
postgresqlの実用的な範囲って、データ量どれくらいなのでしょうか？
色々質問ばかりですいません。

46:NAME IS NULL
07/12/17 14:00:41
自分は詳しくないので、答えられませんが、
詳細環境も提示したほうが答えやすいかも。
少なくともPostgreSQLのバージョンは。

47:NAME IS NULL
07/12/17 14:47:10
DB触り始めで大量データ扱うと、最初にぶつかるよなこれ。
SELECT文で条件指定しないで全取得すれば、データ全取得しようとするから
遅いし、（クライアントの）メモリが足りなくなるよね。

とりあえずは、条件設定したり、LIMIT OFFSET で件数絞ってやってごらん。

48:NAME IS NULL
07/12/17 14:50:17
条件設定して件数が少なくても遅いなら、プライマリキーやインデックスがどうなってるかもチェック

49:NAME IS NULL
07/12/17 16:18:17
>>47
サーバではなくクライアント側のメモリが足らなくなるというのがポイントですな。
クライアント側では、普通、何万件オーダーのSQLの返りを受け取れるようにはできていないので。

50:NAME IS NULL
07/12/17 16:19:54
カーソルの使い方覚えて、例えば10万件ずつFETCHするような
クライアントプログラムを書けばいい。
URLﾘﾝｸ(www.postgresql.jp)
URLﾘﾝｸ(jdbc.postgresql.org)

あとは、年月毎や銘柄毎でテーブルのパーティショニングを行うとかかね。
常にデータ全体をスキャンする必要があるならあまり意味無いけど。
URLﾘﾝｸ(www.postgresql.jp)

51:NAME IS NULL
07/12/17 17:00:25
まずはcout(*)でチェクしてから、
Limit とかoffset で抽出してみるのわ？

52:NAME IS NULL
07/12/17 17:03:15
count(*) ですね。
これもインデックス無いとかなり時間かかると思う。

53:NAME IS NULL
07/12/17 17:11:04
COUNT() ってインデックス関係あるんだっけ?

54:NAME IS NULL
07/12/17 17:54:48
WHERE句入ってれば場合によっては

55:50
07/12/17 18:00:28
8.3では同期スキャンの副作用でSELECTの度に結果が変動するリスクがあるため、
ORDER BY を付けずに LIMIT, OFFSET を付けたSELECT文の実行を繰り返すと妙な事になるかもしれない。
URLﾘﾝｸ(journal.mycom.co.jp)

全体のデータを取り出したいのであれば、
SELECT * FROM hoge ORDER BY idhoge LIMIT 10000 OFFSET $1; （$1には数字を入れる）
みたいなSQL文を複数回実行するより
SELECT * FROM hoge ORDER BY idhoge;
のカーソルを作ってFETCHを繰り返した方がレスポンスは良くなると思う。
（カーソルを使わないとSELECTの度にソートが行われてしまうかも？）
結果がソートされてる必要も無ければ、ORDER句も外せてさらに快適に。

56:NAME IS NULL
07/12/17 18:15:11
大昔に DB2 調べてて、ORDER BY + FETCH FIRST n ROWS ONLY 使うと
n 件の行を取ってきた後にソートするという動きで金玉もげるかと思ったのを思い出した。

57:NAME IS NULL
07/12/17 22:05:56 VmIYEZ1r
みなさんありがとうございます。
ようやくinsertが終了しました。
kabu=# SELECT count(*) from stock_data;
count
----------
73056656
(1 row)

主キーは、日時、会社コード1、会社コード2、の3つです。
会社コード別か、日時を範囲指定して、selectすることが多いと
思うので、それらにインデックスを設定しようかと思います。
（インデックスって勝手には設定されないですよね。）

あと、カーソルというのを調べてみます。存在すら知りませんでした。
テーブルを分けるというのは考えてみませんでしたが、上記のことを
やってみてダメだったら考えます。でもINSERTのやり直しは嫌だなあ。

それにしても、データだけでディスクをかなり占領するし、メモリ確保関係の
エラーにも何回も遭遇するし、大量データを扱うのは大変ですね。
これ以上データサイズが増えるととても扱いきれないと思いました。

あと、バージョンは、postgresql-8.2.4-27 となってました。
openSuSEのrpmのバージョンです。
ありがとうございました。

oracleとmysqlはやってみてあとで報告します。

58:NAME IS NULL
07/12/17 22:11:07
>>57
ノートPCでメモリ2Gでクライアント&サーバをやって
> それにしても、データだけでディスクをかなり占領するし、メモリ確保関係の
> エラーにも何回も遭遇するし、大量データを扱うのは大変ですね。
ってそりゃあ、おいおいって感じだ。

59:NAME IS NULL
07/12/17 22:16:00
零細がダイレクトメール用の情報扱ってるみたいな状況だな。

60:NAME IS NULL
07/12/17 23:17:42
7300万件w

61:NAME IS NULL
07/12/18 09:32:43
慣れればどうってことないけど、最初は少ない数でいろいろやったほうが
操作も覚えるしいいと思うがな

62:NAME IS NULL
07/12/18 14:06:28
>>57
データベースシステムを図書館と司書さんに例えると、
----------------例え話----------------------------
お客(クライアント)は、司書さんに「○○の本を貸してください(SELECT * FROM xxx WHERE ○○)」と問合せをかける。
お客は問合せの結果をバッグに入れてユーザーの所まで持ってくるわけだ。

藻前さんが最初にやったのは、図書館の本全部を一気にバッグに入れて持ってこさせようとした。そりゃ無理だ罠。

だからこそ、「○○な本のうち、50音順で500冊目から100冊持ってきて」という様に要求を区切って出したり、
「○○な本全体で、△△という単語が何回出現するか数えてきて」と集計する要求を出したりするわけだ。

DBのテーブルを分類ごとの書架だとすると、
その書架でも本がすごく多いモノ(例えば小説とか)を一定単位(作者別とか)で仕切るのをパーティショニングという。
パーティショニングされていないと、司書さんは書架全体の中から探す事になり、時間が掛かる。

インデックスっていうのは、図書館の蔵書を管理するカードの様なもので、それを元に検索すると素早く検索できる。

いくら司書さんが、本の扱いに慣れていても、一瞬一瞬に扱う本は1冊づつで、
その時扱っている本(インデックス含む)を差す指がカーソルという事だ。
----------------例え話----------------------------

株価のデータベースで、過去も含めた全てのデータを集計もせずに取り出す場面が(バックアップ目的以外で)あるとも思えない。
バックアップ用途なら、ダンプを取れば良いし、集計クエリやら条件付けやらをして、取り出す件数を絞れば、
メモリ不足でクライアントが動かなくなる事態がそうそう頻発するとは思えない。

OlacleやらMySQLにデータを移すなら、共通に使えるクライアント(ODBC等)経由で、
PostgreSQLのテーブルからSELECT INTOとか使って一気に流し込んじゃう方が楽だ。

63:NAME IS NULL
07/12/18 23:20:02 /fynqWlS
これかなーり便利だわ
URLﾘﾝｸ(pgfoundry.org)

64:age
07/12/18 23:53:42
よくわからないけど、自分には関係なさそう

65:NAME IS NULL
07/12/19 00:45:26 kklpHsFG
>>63
パフォーマンスチューニングするのに使えそうね。

そういえば8.3の全文検索機能試してる人いる？

66:NAME IS NULL
07/12/19 00:50:25
Ludia は試して…　みたい

67:NAME IS NULL
07/12/19 10:38:38
>>62
57じゃないが、勉強になったThx

68:NAME IS NULL
07/12/21 03:10:15 fwC7Qy9u
JPUGの忘年会は盛り上がったの？

69:NAME IS NULL
07/12/21 10:46:56
あー、昨日だっけ。
参加できたなー、申しこむんだった

70:NAME IS NULL
07/12/27 00:25:14
v8.3はまだRCも出てないんだね

71:NAME IS NULL
07/12/27 08:24:23 YLT4m45U
57です。
色々勉強になりました。(62の方とか)
ところでoracleとmysqlとの比較ですが、ノートではきついので
別のマシンでやることにしました。postgresqlへのinsertは終わったのですが、
mysqlとoracleへの移行で止まってます。

> OlacleやらMySQLにデータを移すなら、共通に使えるクライアント(ODBC等)経由で、
> PostgreSQLのテーブルからSELECT INTOとか使って一気に流し込んじゃう方が楽だ。
これについて、もう少し具体的におしえてもらえませんか？
一方のDBからselect * from tableとかでデータを読み込んで、それをselect into
で別のテーブルに流し込むんですよね？それはpsqlの中で行えますか？

上の内容が分からなかったので、postgresqlにダンプをsqlで出させて移行しようと
思ったのですが、(例えばmysqlについては、こんな感じ)
# pg_dump -d kabu > dump_file
# dump_fileを編集(テーブル一個の単純なDBなので、これは簡単そう)
# mysql -u root kabu < dump_file
これよりも速くできると思われるでしょうか？

72:NAME IS NULL
07/12/27 10:49:45
スクリプト書いて両方にアクセスするって話でしょ？
psqlでDOBC使わないし。
ODBC使うツールでやってくれるやつもありそうだけど。

まあ実行可能ならdumpしたSQL食わせるのでいいと思うよ

73:NAME IS NULL
07/12/28 07:27:58
>>71
> # pg_dump -d kabu > dump_file
> # dump_fileを編集(テーブル一個の単純なDBなので、これは簡単そう)
本当に編集が簡単と思っているのか？
7000万件INSERTした結果のdump_fileなんだぞ？
なんか最初から見てるけど、感覚がおかしい。

74:NAME IS NULL
07/12/28 12:36:23 e6yBnBlw
>>73
テーブルが一個しかなくて、編集といっても、create tableと
insert 以外を削除するだけで、7000万件のinsertには触らなかったので、、、、
スクリプト(ruby)を書いてなんとかやりました。
いまmysqlのDBにinsert中です。
insertが始まってから3時間くらいですが、もう4000万件を突破しました。
select count(*) from table;
も速いし、とりあえずmysqlのほうが速そうな感触を持ちました。

ところで7000万件がDBとして多いのかどうかいまいち見当がつかないのですが、
株価のデータとしては仕方ないというか、みんなこれくらいのサイズになって
しまうと思うのですが、大体では、
3000(上場の会社数)×340(一年で市場が開いている日数)×80(データのある年の数)＝81600000
になります。(実際には昔に行くほど会社数が少なくなる)
これはやはり、多すぎると考えるべきなのでしょうか？
それともDBの使い方がまずいのでしょうか？

75:NAME IS NULL
07/12/28 12:42:12
>>74
少なくとも
> それともDBの使い方がまずいのでしょうか？
なんてことを書いているようなレベルの人には
> これはやはり、多すぎると考えるべきなのでしょうか？
多過ぎるかと。

76:NAME IS NULL
07/12/28 12:48:55
>>74
抽出条件に対して適切にINDEX張ってれば
そんなに多いって訳でもないと思うが…
>>75の言うことももっともだと思う。

77:NAME IS NULL
07/12/28 14:39:10
少ないデータで仕組みきっちり作ってから
大量データ流し込んでチューニング

78:NAME IS NULL
07/12/28 21:26:08
>>71
いまさらだろうが、クライアントPCにMS-ACCESSと各DB用のODBCドライバをインスコして、
テーブル構造だけ先に作って、
INSERT INTO コピー先 (項目1,・・・,項目n) SELECT 項目1,・・・,項目n FROM コピー元;
とかやれば、変に編集する手間もなくコピれる。

藻前さんが何をやりたいのか今ひとつ理解できないが、
MySQL、Oracle、PostgreSQLのどれを選ぶかの目安を書いてみようと思う。
・クライアントプラットフォームが多種多様になる場合
　 → ストアードプロシージャによるビジネスロジックの共通化が有効
　　 → OracleかPostgreSQL
・ webなどクライアントが1種類のみで処理スピードの高速化が必要な場合
　 → DB単体でのスピードを優先
　　 → MySQL
・ DB未経験でこれから色々なシステムを構築するための勉強の場合
　 → ストアードプロシージャに慣れておく事は有効
　　 → OracleかPostgreSQL
って感じだと思われ。

OracleとPostgreSQLだが、仕事として見た場合、
・客の予算が少ない or 面倒事を自分でやってでも金が欲しい時はPostgreSQL
・客の予算がとても多い and (客がうるさい Or 忙しいので面倒事をサポセンに任せたい)時はOracle
・客の予算が少ない and (客がうるさい Or 忙しいので面倒事をサポセンに任せたい)時は仕事自体をお断りする
って感じだと思われ。

79:NAME IS NULL
07/12/29 08:56:26
仕事自体お断りする権限がないときは辞めるしかないか・・・

80:NAME IS NULL
07/12/29 10:08:24
>>79
作るだけ作って辞めるのもアリだなwww
ﾄﾞｷｭﾒﾝﾄ?　ﾒﾝﾃﾅﾝｽ?　ｼﾗﾈwww

81:NAME IS NULL
07/12/29 20:30:37
>>79
お断り出来ないときは、見積でふっかけましょう。

メンドクサイ客で予算が少ない時は、見積次第で客をコントロールする事は可能です。
自社の営業がヘッポコな時はむずかしいですが、
自社の営業を接待漬けにするぐらいの勢いがあれば危機対応能力は向上すると思います。

82:NAME IS NULL
07/12/30 22:50:01
見積もりで吹っかける→「いやーそれは高いでしょう」→見積もり減

見積もりするけんｇ（ry

83:NAME IS NULL
07/12/31 02:37:49
そうですか　この見積もりでだめだとしますと他をあたっていただく事になりますが。

84:NAME IS NULL
07/12/31 13:18:59
つ～か、最初から予算ありきで
「お前らの見積なんぞ知らんがな。とにかくこれだけの金で作れ。」
・・・ってところも多いがな。

85:NAME IS NULL
07/12/31 17:03:38 n233Vr/g
8.3日本語版はいつでんの？

86:NAME IS NULL
08/01/02 10:20:25
日本語版って何よ

87:NAME IS NULL
08/01/02 14:47:49
すごいくだらないことかもしれなけど質問させてください。

ユーザーを管理するテーブルって何て名前にしてます？
user
はすでにあるみたいで使えないし
"user"
にすると、セレクトかける時も"user"にしなきゃならないし
tbl_user
とか接頭語や接尾語つけるのはあんまり好きじゃないし・・・
users
っていうのも考えたけど、なんでユーザーだけ複数なんだ？って感じだし

どうして、こんな一般的にみんな使いそうな名前を初期で入れてるだよ～
他の名前にしてくれればいいのに
まあ、どうでもいいから好きなのつけろって言われそうだけど、皆さんどうしてます？

88:NAME IS NULL
08/01/02 15:02:56
affiliate, associate, brother, comrade, constituent, fellow, joiner, member, sister
どうでもいいから好きなのつけろ

89:NAME IS NULL
08/01/02 17:13:26
>>86
URLﾘﾝｸ(www.postgresql.jp)

90:NAME IS NULL
08/01/03 01:08:09
>>89
本体は日本語版も何も無いだろう

91:NAME IS NULL
08/01/03 16:09:34
>>87
passwd

92:NAME IS NULL
08/01/03 17:34:40
>>90
そもそも本体の話しはしてない禿

93:NAME IS NULL
08/01/05 11:36:26
>>87
usertbl

94:NAME IS NULL
08/01/05 12:38:26
Oracleと性能比較した資料てどこかにある？

95:NAME IS NULL
08/01/05 12:58:23
>>94
そんな資料は出せないはず。Oracleが禁止してなかったっけ？
昔の話だから、今はどうか知らないけど。

96:NAME IS NULL
08/01/05 20:22:55
データ型として配列を使っています。
配列の要素にNULLが存在する場合にマッチするクエリは、どのように記述するのか教えてください。

PostgreSQL 8.3beta4です。

97:NAME IS NULL
08/01/05 20:45:32 Ible2iRH
URLﾘﾝｸ(click.j-a-net.jp)

98:NAME IS NULL
08/01/06 12:11:23
>> 96
自前で比較用の関数用意するしかないんじゃね。
ANYとIS NULLの組み合わせじゃダメだし。

99:NAME IS NULL
08/01/06 20:18:51
>>98

ありがとうございます。次のテーブルに対して、
下記のクエリを作成することで対処しました。遅いですが。

create table tbl(pkey integer primary key, a integer[] not null);

select * from tbl t1 where exists(
select * from (select a,generate_series(array_lower(a,1),array_upper(a,1)) from tbl t2 where t1.pkey=t2.pkey) as t3(a,i) where a[i] is null
);

100:NAME IS NULL
08/01/07 12:56:11
URLﾘﾝｸ(itpro.nikkeibp.co.jp)

このページのConstraint Exclusionは、条件に合う部分だけ検索がかけれるということなのでしょうか？
実際に試してみたところ、テーブル内を全て検索するのと速度があまりかわらないような気がするのですが・・・

PostgreSQL 8.2.5です

101:NAME IS NULL
08/01/07 23:12:54
2008-01-07 Cumulative Security Update Release (8.2.6, 8.1.11, 8.0.15, 7.4.19 and 7.3.21)
URLﾘﾝｸ(www.postgresql.org)

PostgreSQL 8.3RC1 is out.
URLﾘﾝｸ(www.postgresql.org)
URLﾘﾝｸ(www.postgresql.org)

102:NAME IS NULL
08/01/07 23:19:12
っと、まだ8.3rc1はアナウンスされておらず勇み足だったらしい。すまぬ。

103:NAME IS NULL
08/01/08 08:03:14 NK7MHFFt
今朝見たらアナウンスされてました。
しかし8.3は難産ですね。RCも1で終わってくれるのかな･･･？

104:NAME IS NULL
08/01/08 08:52:18
URLﾘﾝｸ(www.postgresql.org)
URLﾘﾝｸ(archives.postgresql.org)

8.3rc1のアナウンスはまだじゃない？と見てたら、pgAdminIII 1.8.1 が出てるね。

pgAdmin III v1.8.1 released
URLﾘﾝｸ(archives.postgresql.org)

105:NAME IS NULL
08/01/08 12:50:49
PostgreSQLに危険なセキュリティ・ホール，管理者はバージョンアップを
URLﾘﾝｸ(itpro.nikkeibp.co.jp)

106:NAME IS NULL
08/01/08 23:54:49
PostgreSQLに脆弱性：バージョン7.3ブランチのサポート打ち切りに
URLﾘﾝｸ(builder.japan.zdnet.com)

PostgreSQL 7.3ブランチが終了：8.2系へアップグレードを
URLﾘﾝｸ(builder.japan.zdnet.com)

後者の記事は、Windows版バイナリとそれ以外のEOLの話をごっちゃにしているのが何とも。

107:NAME IS NULL
08/01/09 03:56:47
Windows版 8.3 に期待してるのだけど
通常、PC-Unix 版に比べてどのくらい遅れてリリースされるのかな。

108:NAME IS NULL
08/01/09 20:39:00
>>107
普通は遅れはほぼゼロ。

109:NAME IS NULL
08/01/10 00:13:06
sequenceをデフォルトテーブルスペース以外に作成する方法はないんかいな？

マニュアル見ても、create/alter でテーブルスペース指定することはできないし、
serial型で自動作成されるsequenceも指定できないし。（テーブルが別テーブルスペースでもsequenceはデフォルト域になってしまう。）
最新の8.3でもだめそう。
だれかこの件について情報持ってないですか？

ちなみに、pg_classのテーブルスペース情報をupdateして、物理ファイルをmvしたら、なんとなく動いてるいるようには見える。が、さすがに本番では怖いのでやってない。

110:NAME IS NULL
08/01/10 02:13:10
>>108
サンクス

111:NAME IS NULL
08/01/10 02:13:20
>>109
そもそもSEQUENCEを別のテーブルスペースに作成する意味はあるの？
メリットが分からん。

あと、pg_classをUPDATEしなくても、移動した物理ファイルに対して、
ln でリンクを作ってやればいいんじゃない？

112:NAME IS NULL
08/01/10 07:28:05
>> 109
設定パラメータ default_tablespace を変更してもダメ？

>> 111
> SEQUENCEを別のテーブルスペースに作成する意味はあるの？
誰しもそう思っているから、むしろ忘れられていたのかも。
機能としてはあってもかまわない気はする。

113:NAME IS NULL
08/01/10 21:50:07
java+tomcatであるテーブルの列を５０づつ表示するロジックを作ったとします。
まずはじめの0～50は正常に表示されるのですが次の50を表示するを選択すると
50～100までの表示ではなく50～ラストまでの表示になってしますのです。
SQL文は次のようになっています"select * from -- where number > "+number+" and number <= "+number+50;
何か間違っていることがあれば指摘してください。お願いします。numberの変数はデバッグで意図した値な事を
確認しています。なおnumberはserialです。

114:NAME IS NULL
08/01/10 21:53:18
>>113
知らんがな。実際に発行されているSQL文を0～50と50～100の時で
どうなってるか確認して、psqlで実行してみなよ。

115:NAME IS NULL
08/01/10 22:22:12
LIMIT OFFSET のが簡単な気も

116:NAME IS NULL
08/01/10 23:01:47
>>113
全然関係ないけど、実験の時でも普段から PreparedStatement 使うようにしとくといいぜ。

117:NAME IS NULL
08/01/11 00:05:06
>>113
String + int + int って、((String + int) + int) って解釈されね？
n = 0 なら "number <= 050" で上限は 50 と解釈されるけど、
n = 50 だと "number <= 5050" になる気がするんだが。
「number <= " + (number+50)」と括弧を付ければ良いのでは。

118:NAME IS NULL
08/01/11 00:14:40
同じ演算子の優先順位は左から右だから >>117 の通りだよ。

int n = 50;
System.out.println("select * from ... where number > " + n + " and number <= " + n + 50);

↓結果

select * from ... where number > 50 and number <= 5050

あと Statement は事故の元だから PreparedStatement 使え。

119:NAME IS NULL
08/01/11 00:51:40
>>111
>>112
レスありがとうございます。

>>111
SEQUENCEを別のテーブルスペースに作成するメリットは、
テーブルを別のテーブルスペースに作成するメリットと同等と思ってます。
つまり、SEQUENCEのNextValを取得する際のI/O分散です。

>>112
default_tablespace を変更してから作成しても、だめなようです。

alter database db_hoge set defalult_tablespace = tablespace_hoge;
した上で、
crate table table_hoge( colume_hoge serial ) ;

したら、table_home は、tablespace_hoge 上に作成されますが、
colume_hoge の sequence は、oid = 0 の tablespace 上に作成されてます。

120:113
08/01/11 09:06:04
詳しい説明ありがとうございます。

121:113
08/01/11 09:08:10
が、numberはintです。

122:NAME IS NULL
08/01/11 09:11:29
>>121
だからさぁ、PostgreSQL的にはそんなことどーでも良いんだよ。
サーバ側で処理したSQLをチェックしろ。
意図した通りのSQLになっていて、取得結果がおかしいなら
ここで質問するのはありだが、プログラムの間違い探しなら
よそでやれ。

123:113
08/01/11 09:29:57
失礼しました。>117様の言う通りでした。

124:NAME IS NULL
08/01/11 11:14:28
"select * from -- where number > " や " and number <= " は文字列だからな。
しかしどれ使うにしても、ORDER BY つけないとな。

そして、実行するSQL文を吐き出してpsql等で確認するのは常に必須。

125:NAME IS NULL
08/01/11 15:38:10
あらかじめ用意されたテーブルicmpを

create table d22t11(check(time < '2005-11-22 12:00:00' and time >= '2005-11-22 11:00:00)) inherits(icmp);

というように時系列で分割した後、constraint_exclusionパラメータをonにしてSELECT文かけてみたんですが、分割前と検索速度が変わっていません・・・。
もしかして分割してからデータを挿入しなければならないのでしょうか？

126:113
08/01/11 20:54:51
>124 なるほど～order by という便利なソート機能があったんですね。
更新すると列が最後尾にくるので"どうしたもんか？"と思っていたところでした。
情報ありがとうございます。

127:NAME IS NULL
08/01/11 21:42:42
>>119
> つまり、SEQUENCEのNextValを取得する際のI/O分散です。
それはさすがに意味ないと思う。千～万単位で SEQUENCE 作るつもりでない限りは。
たいていはキャッシュに乗ってる。
バックアップなり信頼性目的ならば、ありうる状況かも。

128:NAME IS NULL
08/01/11 23:34:41
>>127
今回の疑問は、そもそも、sequenceのテーブルスペース変更はできないのは何故なのか？
という好奇心的なものが発端でして、実質的に問題が発生しているわけではありませんけどね。
対応してないなら仕方ないですね。少し残念です。

129:NAME IS NULL
08/01/12 01:08:46
>>125
それは、どう変わることが期待されてんの？

130:NAME IS NULL
08/01/12 11:39:49
>> 125
timeを検索条件にした？

131:NAME IS NULL
08/01/12 12:31:21 bIgQT3Xd
>>125

Ａというテーブルが親なら、　Ａ1　Ａ２　Ａ３　Ａ４という子の
テーブルを継承で作成する。そんで、Ａ１　Ａ２といった子に
insert する。そうすると親のＡに対してselect すると、子を見て
くれて、制約があれば関係ないのは除外するという仕組み。

132:NAME IS NULL
08/01/14 19:14:38
質問です。
2つのテーブル、TABLE_A と TABLE_B があります。
両者のカラム構成は同じです。
現在、使用しているテーブルは TABLE_A です。TABLE_Bは使われていません。
TABLE_B にデータ列を挿入します。
その後、両者のテーブル名を入れ替える操作を次のようなSQLで行います。

BEGIN;
ALTER TABLE "TABLE_A" RENAME TO "TABLE_TMP";
ALTER TABLE "TABLE_B" RENAME TO "TABLE_A";
ALTER TABLE "TABLE_TMP" RENAME TO "TABLE_B";
COMMIT;

このように、テーブル名をスワップする際、データ量とかによっては、
TABLE_Aにアクセスできない時間が発生するのかどうかが疑問です。
(リネーム時に何かしらデータ量に応じた処理が行われますか？)

上記テーブルデータは、WEBサービスで使うデータで、
WEB上からユーザーがアクセスしてきた際に、呼び出されます。
アクセスのタイミングによっては、ユーザーには、空データが表示されてしまうのでしょうか？

よろしくお願いします。

133:NAME IS NULL
08/01/15 01:04:38
>>132
> (リネーム時に何かしらデータ量に応じた処理が行われますか？)

行われない。
たぶんシステムカタログの一部が更新されるだけ。

> アクセスのタイミングによっては、ユーザーには、空データが表示されてしまうのでしょうか？

一瞬だけど TABLE_A が存在しないタイミングがあるから、
そのときのアクセスはエラーになる。

134:NAME IS NULL
08/01/15 01:25:31
エラーじゃなくてテーブルロックの解除待ちじゃないかな。
他からTABLE_AとTABLE_Bを順次SELECTされた場合、
タイミングによっては片方のテーブルを2度読みしちゃう可能性があるけど。

135:133
08/01/15 02:02:36
>>134
ALTER 文が BEGIN, COMMIT で囲まれてるの見のがしてた。
ロック待ちだね。

> 他からTABLE_AとTABLE_Bを順次SELECTされた場合、
> タイミングによっては片方のテーブルを2度読みしちゃう可能性があるけど。

1トランザクションで ALTER 文を全部実行してるから、2度読みはないはず。

136:134
08/01/15 02:45:10
>>135
> 1トランザクションで ALTER 文を全部実行してるから、2度読みはないはず。

TABLE_Aを読み出して、TABLE_Bも読み出そうとしたら >>132が走ってロック待ち、
解除後TABLE_Bを読み込んだら、それはリネームされる前のTABLE_A。

137:NAME IS NULL
08/01/15 07:53:27
>>136
最初に全部ロックを取ってしまうのはどうだろう。
BEGIN;
LOCK TABLE_A IN ACCESS EXCLUSIVE MODE;
LOCK TABLE_B IN ACCESS EXCLUSIVE MODE;
...

138:NAME IS NULL
08/01/15 08:06:32
ていうかそういうのは読み込み側がトランザクション分離レベルやテーブルロックを適切に設定してないだけじゃん。

139:NAME IS NULL
08/01/15 12:57:46 L9najbhe
※nextval(text)とcurrval(text)について
PHPからDBにアクセスしIDを表示するようなシステムを作っています

CREATE TABLE test_tbl (id SERIAL PRIMARY KEY,memo TEXT);
というテーブルがあり
idカラムの番号を表示で利用する場合
１）が正しい気がしますが２）でも大丈夫なきもします
１）と２）どちらがpostgres(DB)としては安全で正しい運用方法
なのか教えていただけないでしょうか？

１）IDを前もって取得し変数($id)に入れて使いまわす方法
SELECT NEXTVAL('test_tbl_id_seq');
BEGIN
INSERT INTO test_tbl(id,memo)VALUES($id,'AAAA');
COMMIT

２）IDを後から取得して使う方法
BEGIN
INSERT INTO test_tbl(memo)VALUES('AAAA');
COMMIT
SELECT CURRVAL('test_tbl_id_seq');

140:NAME IS NULL
08/01/15 22:40:11
>>135
ふつう、DDLにトランザクションは効かないか発行時点でcommitされてしまうと思うが。

と思って調べてみたら、SQLServerはDDLもrollbackできるんだな。

141:NAME IS NULL
08/01/15 22:43:09
DB2 でも普通にできるが。

142:NAME IS NULL
08/01/16 00:22:19
>>136
両テーブルのSELECTも、トランザクションで実行するもんだと思うが。

143:NAME IS NULL
08/01/16 00:55:16
>>139
どっちでも完全に一緒。お好みで。
PostgreSQLの方言でよければ RETURNING もアリ。
INSERT INTO test_tbl(memo) VALUES('AAA') RETURNING id;

144:NAME IS NULL
08/01/16 01:13:31 13aLpW9J
>>133-138
>>140-142

ご回答ありがとうございます！
大変参考になりました！

ただ、考えてみれば、
テーブルデータ更新中のアクセスに対応するための方法だったので、
更新失敗によるデータ破損や、自前の例外処理を心配するぐらいなら、
最初から1テーブルで、データ更新 (COPYで行う) 自体をトランザクションで行う方が安全だと気づきました…。
で、シーケンスを更新する、と。

ただ、空データ表示時間があったとして、その機会損失損害額を考えると
どういう方法がベストなのか今でも分かりませんが…。

ああ、SEへの道は遠いなぁ…。

皆さん、どうもありがとうございました！

145:NAME IS NULL
08/01/17 04:44:40 EaOIQdVo
Sun、MySQLを買収へ
URLﾘﾝｸ(www.itmedia.co.jp)

Sun Microsystemsは、オープンソースのRDBMS「MySQL」を開発するMySQLを
総額約10億ドルで買収することを明らかにした。

　Sun Microsystemsは1月16日、オープンソースのRDBMS「MySQL」を開発する
MySQLを総額約10億ドルで買収することを明らかにした。
買収は3月末をめどに完了させる予定。MySQLはIPOを待たずして買収されることとなった。

　MySQLが自社サイトに開設しているブログに、同社のコミュニティ担当バイスプレジデント、
カイ・アーノ氏がその旨を伝えるエントリを投稿したのとほぼ同時期に、
Sunからも正式なプレスリリースが出されている。

　カイ氏はエントリの中で、「オープンソースをよく理解しているSunがMySQLを買収したことは、
MySQLコミュニティーにとっても有益なものになる」と述べている。

　一方、Sunのジョナサン・シュワルツCEOも自身のブログでこの件について言及、
MySQLの顧客に対して買収の完了を待つことなくサポートサービスの提供を開始する予定であると述べた。

　MySQLについては、過去にOracleが買収を試みたことが知られている。
今回Sunが買収したことで、OracleやMicrosoft、
IBMなどとデータベース市場で争うための基盤をSunは手に入れたことになる。

146:NAME IS NULL
08/01/17 10:49:44
8.3で忌まわしきVACUUMが無くなるって話を聞いたんだが、これって公式にアナウンスされてる？
もしVACUUMが無くなるならば、ようやく使えるDBになるな
速度の問題だけじゃなくて、VACUUMの手間を避けたいがゆえにMySQLに行った人って多いでしょ

147:NAME IS NULL
08/01/17 10:53:35
> 今回Sunが買収したことで、OracleやMicrosoft、
> IBMなどとデータベース市場で争うための基盤をSunは手に入れたことになる。

(　´д)ﾋｿ(´д｀)ﾋｿ(д｀　)

148:NAME IS NULL
08/01/17 12:27:46
バキュムはどっかでやってるだけでしょ。
てか普通に空いた時間でやってくれてると思うが、
そんなに面倒かな。

149:NAME IS NULL
08/01/17 16:25:33
>>148
My SQL使いは Auto VACUUM の存在を知らない人が多いよ
というか、もはやPostgreSQLに目もくれないご様子で…

150:NAME IS NULL
08/01/17 18:08:10
なんでMySQLの話題ばかりなんだよ。
というわけで
SRA OSS、PostgreSQL 8.2をベースにしたHAクラスタソリューション
URLﾘﾝｸ(enterprise.watch.impress.co.jp)
なんて話題を振ってみる。

HAクラスタソフトにはLifeKeeperを使っているとのこと。

151:NAME IS NULL
08/01/17 18:41:57
>> 150

> ベースとなるPostgreSQLが8.2.5へバージョンアップ。

最近のセキュリティフィックス入ってないじゃん。

152:NAME IS NULL
08/01/17 21:56:40
まぁデフォルトで autovacuum が on になるから、
「設定不要になった」と言っても嘘にはならないだろう。

「VACUUMが無くなる」という発想そのものは、何も分かっていない証拠。
Oracle で UNDO セグメントを無くせないとのいっしょ。

153:NAME IS NULL
08/01/17 22:14:51
どうでもいいから日本postgresqlユーザ会、8.3の日本語版早く出してくれ。

154:jin
08/01/18 11:18:11 EMckNTsF
Postgre for windowsのチューニングについて教えてください。
64bit版の機器で16GBのメモリをつんだ機器でポスグレをインストール
したのですが、Shared Memoryを1GB以上にするとポスグレが起動できません。
16GBつんでるのでメモリを最大限まで使用したいです。どうしたらいいので
しょうか。教えてください。

155:NAME IS NULL
08/01/18 15:22:21
>>154
バージョンいくつ？バイナリは32ビット版だよね？

156:154
08/01/18 16:10:40
サーバー用にOS:VISTA PC買ったらPOSTGRESQLインスト出来ねえでやんの；
その時オワタおもた。

157:NAME IS NULL
08/01/18 16:12:26
失礼。ミスた俺は>154じゃない。

158:NAME IS NULL
08/01/18 23:01:42
Windows 用の 64bit バイナリってあったっけ？
少なくとも配布されているのは 32bit 版だけだったような…。
必ずしも shared_buffers にメモリを全部割り当てる必要は無いから
(OSがキャッシュに使ってくれる) 1GB で我慢しれ。

159:NAME IS NULL
08/01/20 00:59:56
URLﾘﾝｸ(japan.cnet.com)

> 最近利用が増えてきているPostgreSQLと比較しても、約2倍ほど
> 高速に動作します。

デマが流れてるぞ

160:NAME IS NULL
08/01/20 01:42:32 rsAddFWz
>>159
だれだ　さぁや　って知ったかライター（インチキ）か。

posgreSQLにもMySQLにも迷惑だ。潰してやれ。

161:NAME IS NULL
08/01/20 13:27:12
>>160
迷惑だと言えば、MySQLスレに出張して、
やたらとSunの買収について不安を煽っている人間がいたね。
大人げ無いから止めとくれ。>>152=>>158

162:NAME IS NULL
08/01/20 14:33:36
ゼイタクギガサーバーがあまりにも贅沢すぎるw

163:NAME IS NULL
08/01/20 17:00:55
postgreSQLはMYSQLと比べて便利すぎる。

164:NAME IS NULL
08/01/20 22:18:45
MySQLは商用版も出てたし、業界再編の波に飲まれているのでは？

165:NAME IS NULL
08/01/20 22:51:34
安定して使えりゃどっちでも良いよ

166:jin
08/01/21 09:20:39 Q97Sm1d1
ver.はPostgreSQL 8.2.6です。確かに32bit版のようです。出来る限り16ＧＢ
のメモリを効率的に使用して処理速度をあげたいです。shared_buffers以外
にもどの部分のチューニングをすればいいのでしょうか。教えてください。

167:NAME IS NULL
08/01/21 11:27:09
アナウンスがまだだけど、PostgreSQL 8.3 RC2。
URLﾘﾝｸ(packages.debian.org)

168:初心者
08/01/21 15:28:41
初心者です。

PostgreSQL のユーザ定義関数を使って和暦変換関数を作成したいのですが

IBMのICU4Cを使ってC++で和暦変換関数を作成しました

C++で作った和暦変換関数を組み込もうとしてるのですが、

C関数でないせいかうまくいきません。

誰か詳しい方教えてください。

169:NAME IS NULL
08/01/21 16:48:37
C++で作ったって、外部向け関数だけをCリンケージでやったらいいんじゃないかな。

170:NAME IS NULL
08/01/21 16:49:42
>>156
Vistaへのインストールはコツがいる。
ググってわからなかったらまたおいで。

171:NAME IS NULL
08/01/21 18:42:22
>>168
まず、どのように「うまくいかない」のか書くべし。

postgres のヘッダで、typename や delete なんかの C++ のキーワードを
仮引数名として使っている箇所があったような気がする。
postgres と繋ぐ箇所だけを別のCソースで書くか、
include 前に #define typename typename_ で誤魔化すか。

次ページ