PostgreSQLは最高さ！！

1 ：名無しさん＠お腹いっぱい。 ：2000/12/06(水) 13:10

PostgreSQLは最高さ。
Access？なんだそれは。
そんなもんでデータベース作ってんじゃねぇ。
今の時代はPostgreSQLなんだよ！！

49 ：>>47 ：2000/12/21(木) 00:23

なんでＳＱＬＳｅｒｖｅｒはダメなの。
理由教えてよ。

50 ：名無しさん＠お腹いっぱい。 ：2000/12/21(木) 01:18

>>49
http://www.asia.microsoft.com/japan/support/tdoc/newest.htm
この辺見てると、時々ずらーーーっと気の遠くなる位たくさんのバグ情報
が出てたりすんのよ > SQLServer

# SQLServerに限らずという話もあるが

51 ：49 ：2000/12/21(木) 02:00

>50
なるほど、よく分かったよ。
しかしここまで酷いとは思わなかった・・・

# でもこっちの方が解りやすかった。
http://www.microsoft.com/japan/support/faq/products/sql/Issues/June.asp

52 ：名無しさん ：2000/12/21(木) 03:02

つーか、Postgreのページにもバグ情報がずらっと並んでるから、
真のPostgreユーザーはチェックするように。

53 ：名無しさん＠お腹いっぱい。 ：2000/12/21(木) 03:11

Linux Distributor のサイトにもバグ情報が並んでるから（以下略）

54 ：名無しさん＠お腹いっぱい。 ：2000/12/25(月) 11:26

PostgreSQLはどうした？

55 ：アクセス ：2000/12/28(木) 23:45

ポスグレはカスです。

56 ：名無しさん＠お腹いっぱい。 ：2000/12/31(日) 04:17

オラクルのホームページにはバグ情報が無いなぁ。
バグが一つも無いなんて、すばらしいＤＢだだなぁ。

57 ：名無しさん＠お腹いっぱい。 ：2000/12/31(日) 06:20

おらくるそらくるぼったくる

58 ：名無しさん＠お腹いっぱい。 ：2000/12/31(日) 12:24

いい紹介・説明サイト無いですか？
日本語でおねがいします。

59 ：名無しさん＠お腹いっぱい。 ：2001/01/01(月) 23:07

○ラクルはくそだけど、今でもかなりメジャ
ー。理由は3つ。
1.商用だから誰かがサポートしてくれる
2.レプリケーションをサポートする
　（WANでデータベースを利用するような場
　　合に便利）
3.すでに使ってるから変えるのが大変

60 ：最高なんてねぇよ ：2001/01/01(月) 23:22

PostgreSQL信者やSQLServer信者（Oracle信者も？）は
なんでいつもそんなに鼻息荒くしてるのですか？
RDBソフトひとつに最高だのカスだの、ばかばかしい。。。
RDBエンジニアである以上、論理設計なり物理設計なりに
もうちょっと神経向けることができればいいのにね。

61 ：なまえをいれてください ：2001/01/02(火) 17:29

>60
運用を考えないエンジニアはクソ。

62 ：名無しさん＠お腹いっぱい。 ：2001/01/02(火) 17:38

>>61
RDBの選択で既に思考の停止してるエンジニアはもっとクソ。
他にやらなきゃなんねェコトは、沢山あるんだよ。

63 ：最高なんてねぇよ ：2001/01/02(火) 18:58

>> 61
運用を考えるって何？

64 ：名無しさん＠お腹いっぱい。 ：2001/01/03(水) 00:00

>>61
単純に運用考えるならGUIのすぐれてるSQLServerでは？
あるいはDB2かな。
少なくとも運用面でもDBの機能面や信頼性でも、
現時点では、まだまだPostgreSQLは貧弱だと思う。
でもパーティショニング機能やレプリケーション機能、
オンラインでの差分バックアップができるようになると
もっと強くなると思う。
（現時点ですでにそれら機能があるのなら、
　私の勉強不足です。すみません。）

>>60
確かにRDBってのは設計レベルは大切で、
システムとしての性能を左右すると思うけど、
RDBを管理してる人にとっては、
どのRDBMSがどういう場面で有利かを考えるのは、
大切なことだと思いますよ。
60さんがおっしゃってるのは、
RDB設計者に対してのことですよね。
システム管理者とシステム設計者は別と思います。

65 ：なまえをいれてください ：2001/01/03(水) 17:13

>>64
>単純に運用考えるならGUIのすぐれてるSQLServerでは？
常に人をはりつけておけるなら、そうかも。

そのシステムがどういう条件下で運用されるのかに左右されちゃうので、
一概にGUIが勝れているから・・・ってのは言い切れないと思うけど。

66 ：なまえをいれてください ：2001/01/03(水) 17:15

>>61
>>62
違うジャンルの設計やってる人間じゃないのか？

67 ：なまえをいれてください ：2001/01/03(水) 17:19

>>63
どのようなバックアップが可能か？
ＤＢ止められるなら静的に取ればいいけど、24h365dならオンラインバックアップの
機能を持ってないと駄目っしょ。
それとか、メンテナンスはどの程度の頻度で行うか、運用中にメンテできるのか、
スクリプト等による自動メンテは可能か、人が手作業でやらないといけないか、
どこまでなら自動化できるか・・・
とか、だと思う、よ。

68 ：最高なんてねぇよ ：2001/01/04(木) 03:20

>>64
>>67
「どのRDBMSがどういう場面で有利かを考える」のが不要だなんて
書いてないし、「運用を考え」る必要もないとも書いてません。
ただ、個々のRDBソフトを最高だのカスだの書いてること自体が
ばかばかしいと考えたまでです。

69 ：なまえをいれてください ：2001/01/04(木) 22:01

>>68
63に対する返事、に対する返事としては不適切

70 ：最高なんてねぇよ ：2001/01/06(土) 23:53

>>69
「64に対する…」てこと？
なんで？
1の書き込みをはじめ、他の書き込みも大多数がその根拠もなにもない。
ただ単に最高だのカスだの書くのに何の意味があるの？

71 ：なまえをいれてください ：2001/01/07(日) 00:37

>>70
１はアレだからどうでもいいけど、61→63→64って毛色違わうと思わない？
思わないならいいや。

72 ：名無しさん＠お腹いっぱい。 ：2001/01/07(日) 08:28

PL/pgSQLだかなんだかって使っている人いるんですか？
神の声では結構重宝してたんですが、PL/pgSQLは使っている話を聞いた事が無い

73 ：名無しさん＠お腹いっぱい。 ：2001/01/07(日) 13:17

最高、カス、クズ、最高

74 ：名無しさん＠お腹いっぱい。 ：2001/01/13(土) 22:15

あげ

75 ：名無しさん＠お腹いっぱい。 ：2001/01/16(火) 21:35

PostgreSQLは最高って本当なの？

76 ：名無しさん＠お腹いっぱい。 ：2001/01/16(火) 22:41

本当です

77 ：名無しさん＠お腹いっぱい。 ：2001/01/18(木) 20:19

冴えないプログラマのうちはPostgreが最高に思えてしまう。
たいした違いが見えない（分からない）から。
データベースの運用管理をしだすとだんだんと見えてくる。
Postgreがクソだってことが。
よってこんなクソDBが最高なんて言ってる奴はクソ以下ってこと。

78 ：名無しさん＠お腹いっぱい。 ：2001/01/20(土) 11:39

何が最高かというと、ソフトを手に入れるのに
金がかからないというのが最高なんだろ。（藁）

フリーソフト至上主義のクソどもめが。

79 ：名無しさん＠お腹いっぱい。 ：2001/01/24(水) 01:04

有料ソフトよりも無料ソフトの方がいいぞ！！
コミュニティもしっかりしているし。
無料ソフトの方がサポートに関する情報も多い。

有料ソフトといえば「ＭＹ苦労ソフト」！！
「ＭＹ苦労ソフト」は最悪！！

無料ソフト最高！！

80 ：名無しさん＠お腹いっぱい。 ：2001/01/25(木) 14:31

石井はひげを剃れ

81 ：名無しさん＠お腹いっぱい。 ：2001/01/25(木) 14:46

まだ使いはじめたばっかだからどこがクソなのか
よくわかんないなあ postgres..

82 ：PostgreSQL愛好者 ：2001/01/25(木) 15:17

更新系ＤＢを作って頻繁にバックアップを取ろうとか、多重化を図ろう
と思うようになるとPostgreSQLの限界が見えてくるよ。

83 ：名無しさん＠お腹いっぱい ：2001/01/25(木) 15:18

Oracle、値段高すぎ。高い割にサポートはクソ。
そんなことならフリーでって事になっちゃうよな。
俺も、Oracle使いてー。
でも大抵の場合、Oracleまで持ち出さなくても
って案件ばっかり。

84 ：名無しさん＠お腹いっぱい。 ：2001/01/25(木) 17:08

>>82
Oracleバックアップ遅い

85 ：名無しさん＠お腹いっぱい。 ：2001/01/25(木) 19:07

PostgreSQLでレプリケーション＆パラレルクエリーをやる
データ容量１００Ｇぐらいの巨大データベースつくってくれよ。（藁）

実現できたとして、運用に耐えられるのか？（藁）

86 ：名無しさん＠お腹いっぱい。 ：2001/01/25(木) 20:23

商店街のオヤジのショッピングモールにも Oracle もちだすの？

……ホントにバカだなぁ。

87 ：名無しさん＠お腹いっぱい ：2001/01/25(木) 20:36

>>85
じゃあ、そう言う案件持ってきてくれよ。
Oracleで作ってあげるからさぁ。

88 ：わかってないな ：2001/01/26(金) 00:50

>>86
わかっとらんな。
商店街のオヤジがやるショッピングだったら
客が金を支払ったという記録を失ってもいいのかよ。
Postgreはバックアップの仕組み上、
それが発生する可能性がきわめて大きいよな。
だからPostgreどきゅんは素人の集団だって言われるんだよ。

89 ：名無しさん＠お腹いっぱい ：2001/01/26(金) 01:03

>>88
確かに、Postgresのバックアップが貧弱なのはそうだが、
じゃあ、Oracleのバックアップの仕組みがまともなのか
というと、そんなでも無いな。
売り物だろうが、フリーだろうが、だめなときはだめ。
あと、アプリ作る奴がだめなら、Oracle使ってもだめな
物ができる。ばかとはさみはつかいようさ。

90 ：名無しさん＠お腹いっぱい。 ：2001/01/26(金) 03:22

商店街でPOSもどきをやるなら２４時間営業じゃ無いだろうからPostgresql
でもバックアップは取れるぞ。

91 ：名無しさん＠お腹いっぱい。 ：2001/01/26(金) 03:28

>商店街のオヤジがやるショッピングだったら
>客が金を支払ったという記録を失ってもいいのかよ。

それ以前に導入コスト・・・・

92 ：名無しさん＠お腹いっぱい。 ：2001/01/26(金) 16:27

まとめるとバックアップのマトモにできる、そこそこの性能の
DBエンジンがあれば商店街の親父に感謝されて金が儲かるでいいか＿

93 ：名無しさん＠お腹いっぱい。 ：2001/01/26(金) 16:30

>>92
相対的に安いが抜けとるぞ

94 ：名無しさん＠お腹いっぱい。 ：2001/01/26(金) 18:40

Postgresとinterbaseだったらどっちを選ぶ？
厨房ＤＢだけは選びたくないな。（藁）

95 ：わかってないな ：2001/01/27(土) 00:58

>>89
あんたバックアップの仕組み分かって言ってる？
まともじゃないって、あんた．．．
オンラインバックアップとジャーナリングの仕組みがまともじゃないって？
じゃーどんなのがまともなバックアップなんよ？
それに俺は使う奴のことなんて言ってないだろが。
そんなとこまで知らねえよ。

>>90
ジャーナリングのこと勉強しなさい。

96 ：わかってないな ：2001/01/27(土) 01:05

>>91
導入コスト以前に店の信用
そのリスクを承知してもらった上で導入コストと利益を検討してもらわないとね。

>>92
何言ってるの？

97 ：名無しさん＠お腹いっぱい。 ：2001/01/27(土) 01:06

この議論もうやめようよ…

>>89
> 確かに、Postgresのバックアップが貧弱なのはそうだが、
> じゃあ、Oracleのバックアップの仕組みがまともなのか
> というと、そんなでも無いな。
あんたDB専門じゃないんでしょ？
俺もDBの中身なんかわかんないけど、知らないことに無理にくちば
し突っ込むのやめなよ。慣れてないの使わされるとストレス溜るん
だろうけど、客が金払うって言ったらOracleになるんだから。

98 ：名無しさん＠お腹いっぱい。 ：2001/01/27(土) 01:11

oracleはsaiteiさ

99 ：名無しさん＠お腹いっぱい。 ：2001/01/27(土) 01:12

>>98
煽りカッコワルイ

100 ：わかってないな ：2001/01/27(土) 01:35

誤解を生んだかもしれないが、
俺もPostgreの一ユーザなので、製品自体はすばらしいと思ってる。
バックアップの仕組みがしっかりしてて、
「うそぐれす」の仕組みが信用できるものになったら、
それこそ脅威の存在になると思う。
最近の商用DBの誇大化にはうんざりしてる人は多いだろう。
実際俺もそう思ってるしな。

ただ、その製品の強みや弱み、コアテクノロジーの仕組み等
をよく知らないくせに、大きな口叩いてる素人野郎はクソだ。

101 ：89 ：2001/01/27(土) 02:09

> オンラインバックアップとジャーナリングの仕組みがまともじゃないって？
はいはい。
わりーが、俺はOracleも使うし、Postgresも使う。
たしかにDBのプログラムだけを組んでる訳じゃないが、
まあ、そこそこは使ってると思う。
どっちも一長一短さ。予算がふんだんにあればOracle使うし、
無ければ、Postgresだね。でも、予算があっても、Postgresと
アプリ側を工夫して、事故があっても困らない程度のデータの
再構築ができる様にして、安く上げることもある。
大口叩いてる素人野郎はお前のほーだ。
逝ってよし>>100

102 ：>>101 ：2001/01/27(土) 02:30

答えになってないじゃん。
95の言うオンラインバックアップとジャーナリングをまともじゃないというあんたが考えるバックアップの仕組みってどんなのよ？

103 ：わかってないな ：2001/01/27(土) 02:45

>>101
あんたRDBMSだけでなく、開発そのものも分かってないのでは？
プログラム組む組まないってことじゃなくて。
ま、いいけど。

104 ：89 ：2001/01/27(土) 02:56

じゃあ、どんな時でも、どんな状況でクラッシュしても、
Linux上のOracleでも、Solaris上のOracleでも、二重化
されてないディスク上でも、オンラインバックアップなら
完璧なわけ?　そこまでOracleを信用できるっておめでたいな。
つーか、べつに、オンラインバックアップ機能や、
ジャーナリングって言う技術を個別にけなしてるわけじゃ
ねーぞ。その時どきで、必要なバックアップの方法、それに
かかるコスト、予算に合わせて実装すればいいだけのことで、
もちろん、オンラインバックアップができなきゃならないような
シビアな案件もあるだろうし、そうじゃない場合もあるって
言いたいわけ。

105 ：わかってないな ：2001/01/27(土) 03:28

>>104
バックアップ＋ジャーナルなんてOracle固有のことじゃないよ。
今まで一度だって「Oracle」なんて書いてないだろ。
RDBMSとは書いたが。
結局、バックアップ＋ジャーナルのこと分かってないじゃないの。
それを「まともじゃない」ってよく言えたもんだね。

予算に合わせて実装すればいいなんてそんなの当たり前のことなんだよ。

あと、開発やったことないのではと書いた根拠は、
>>101
>アプリ側を工夫して、事故があっても困らない程度のデータの
>再構築ができる様にして、安く上げることもある。
の部分ね。
工数（人件費）とメンテナンスのことを考えない人は、
自作すれば予算が低くなると信じる傾向があるからね。

106 ：89 ：2001/01/27(土) 10:10

>バックアップ＋ジャーナルなんてOracle固有のことじゃないよ。

そう言う煽り方はみっともねーな。良く読め厨房。

>自作すれば予算が低くなると信じる傾向があるからね。

そりゃ君のような駄目な奴が、駄目なものを自作すれば
人件費もメンテナンス費用も泥縄式に増大していく事で
しょう。

107 ：名無しさん＠お腹いっぱい。 ：2001/01/27(土) 11:41

Postgresで何やるかっつーと、Webアプリがほとんどでしょ？
ODBC使えるとはいえ、C/Sの開発に使ってる人なんているの？

逆にいえば、OracleをWebアプリに使うのは甚だ帯に長いと思う。
プーリングかまして接続速度稼がないと、遅くて使い物にならないしね。
こういう用途にはPostgresの方が管理コストも低くなるだろうね。

や、みんなが同じ土俵の上で議論してるとは思えない発言が多いもんで…

そういうおいらはInterBase。
中規模までならオールマイティーなRDBMSだよ。

108 ：名無しさん＠お腹いっぱい。 ：2001/01/27(土) 17:31

Oracleっていったい何？
使ったことないからどんなのかわかりません。

109 ：名無しさん＠お腹いっぱい。 ：2001/01/27(土) 17:34

Oracleではなく、オラ狂うです。

110 ：名無しさん＠お腹いっぱい。 ：2001/01/27(土) 20:00

ど素人です。
でも、十人満たない総務でOracleをいれようとする会社に
違和感はあります。（やりたいことは書類のデータベース）

111 ：名無しさん＠お腹いっぱい。 ：2001/01/27(土) 21:48

>>109
オラ日本文化にも狂っているだ。
オラの御神託を聞け。

112 ：わかってないな ：2001/01/27(土) 22:56

>>バックアップ＋ジャーナルなんてOracle固有のことじゃないよ。
>そう言う煽り方はみっともねーな。良く読め厨房。

どこが煽りなの。ちゃんと説明してくれよ。
オンラインバックアップもジャーナリングもRDBMSそのものの仕組みだよ。
ちなみにOracleでは、ジャーナリングのことを、アーカイブログ
SQL Serverでは、トランザクションログという。

あんたが何も知らないだけでしょ。煽ってるつもりはねえよ。
もう少しお勉強しなよ。あともっと論理的に反論したらどう？
はたで見てる人はどう思う？

> そりゃ君のような駄目な奴が、駄目なものを自作すれば
> 人件費もメンテナンス費用も泥縄式に増大していく事で
> しょう。

そうだね。第一、私のような凡人が作っても、
普通、そんな仕組みなんて信用してくれないってことなんか
分かりきってるよ。
ただ、ジャーナリングすら知らないあんたはなに？

113 ：わかってないな ：2001/01/27(土) 23:19

#このハンドルあなたに対してではないのでお許しを。

>>107
>Postgresで何やるかっつーと、Webアプリがほとんどでしょ？
>ODBC使えるとはいえ、C/Sの開発に使ってる人なんているの？

確かに私の周辺では聞きませんね。

>逆にいえば、OracleをWebアプリに使うのは甚だ帯に長いと思う。
>プーリングかまして接続速度稼がないと、遅くて使い物にならないしね。

OracleやSQLServerでも接続プーリング機能はありますよ。
それにアプリケーションサーバがプーリング機能持ってる場合もありますし、
その辺はさまざまなレベルで解決法があるんじゃないかな。

114 ：わかってないな ：2001/01/27(土) 23:21

>>110
>でも、十人満たない総務でOracleをいれようとする会社に
>違和感はあります。（やりたいことは書類のデータベース）

そうですね。こういう場合、
足りない部分は、運用で十分カバーしてもらうことも可能でしょうから、
商用のDBMSを入れるまでもないと思います。

#このハンドルあなたに対してではないのでお許しを。

115 ：名無しさん＠お腹いっぱい。 ：2001/01/27(土) 23:22

>オンラインバックアップもジャーナリングもRDBMSそのものの仕組みだよ。
おもしれー主張だな。わかってないのはおめーの方だ。
書くならちゃんと書けよ、なんだかねぇ。

116 ：わかってないな ：2001/01/27(土) 23:27

>>115
>おもしれー主張だな。わかってないのはおめーの方だ。

んじゃー、あなたは何をわかってるの？

117 ：名無しさん＠お腹いっぱい。 ：2001/01/27(土) 23:42

変なチャットだねぇ。。。（ケラケラ。。。

118 ：名無しさん＠お腹いっぱい。 ：2001/01/27(土) 23:56

>>115
おまえが一番分かってないよ。
もういちど勉強しなおしてこい。

ＤＢがこけてバックアップが２４時間前分しかなかったら、
そのＤＢは２４時間分のデータはどうなるのか？失うのか？
もしそうだったら素晴らしいシステムだな。（稾）

119 ：名無しさん＠お腹いっぱい。 ：2001/01/28(日) 00:33

115はばか丸出しで痛すぎる。（ｗ

120 ：名無しさん＠お腹いっぱい。 ：2001/01/28(日) 01:27

Postgresのジャーナリングは、7.1以降のWALということでいいの？

121 ：名無しさん＠お腹いっぱい。 ：2001/01/28(日) 07:08

Accessと比較するところが初心者だね。

122 ：115では無いけど ：2001/01/28(日) 23:00

>オンラインバックアップもジャーナリングもRDBMSそのものの仕組みだよ。
115は
「RDBMSが提供する機能なだけで、RDBMSを構成するのに必須ではない要素じゃないのか？」
といいたかったのでは？

123 ：わかってないな ：2001/01/29(月) 00:03

>>120
7.1以降のWALですか。
不勉強なもので知りませんでした。どういったものか調べてみます。
情報感謝。

>>122
そうなのかなー？
もしそうなのならそれを書いてくれないと、
何を言いたいのか、ほんとわかんなかった。

#このハンドルあなた方に対してではないのでお許しを。

124 ：わかってないな ：2001/01/29(月) 00:33

WAL というのは、Write Ahead Log のことのようですね。
私が見つけた資料にはその説明はなかったのですが、
ジャーナリングの方式として Write Ahead Log を採用するということでしょうから、
バックアップ後の更新記録も保証する仕組みがサポートされるというだと思います。
そうなるとデータ保証のシビアなシステムにも Postgre を使うことが
できるということですね。すばらしいことです。

# 私の解釈が違ってればフォローください。(^^;

125 ：名無しさん＠お腹いっぱい。 ：2001/01/31(水) 22:39

上げてみよ！！

126 ：Sherry ：2001/02/01(木) 04:19

初めて書き込みます〜

WAL，どの程度信頼度があるのか謎ですが，今までよりは
改善されそうですね．
（それより OUTER JOIN サポートの方が嬉しいけど）

わたしはPostgreSQLもOracleも使いますが，好きな方使える
ならやっぱOracle選びますね(笑)

接続が速いといっても，PostgreSQLとOracleではそこまで
大きく違わないです．（MySQLだけは劇的に速いようですが）

PostgreSQLは結構トラブルに逢ったことがあるので，
重要な用途には使いたくないですねぇ．

トラブル１．文字化けしたデータをCGIに投稿されたために
　　　　　　　テーブルのデータが文字化け．
　　　　　　　その結果，pg_dumpall のバックアップファイルで
　　　　　　　２バイト文字の２バイト目に相当するコードと改行が
　　　　　　　くっついて１つの文字になり，リストア出来なかった(爆)
トラブル２．アクセス数が多くなったときにいきなりDBが飛ぶ．
　　　　　　　しかも連続で…．

アクセスが多くてもちゃんと動いてくれる場合もありますが，
やっぱ怖いですね．それに，何かあったときにデータ失う
ことがほとんどなのが，更に痛い．

Oracleは止まったことはある（バグで(笑)）けど，データを
失ったことはまだ０ですし．

あとは，複雑なquery発行したときの速度とか，かなり
チューニング出来ると行った点でOracleは良い．

PostgreSQLの良いところは，読み取り一貫性を実現し，
読み取りと更新が競合しない，そしてなんといってもフリー．
じゃないんでしょうかねぇ．

% Oracleは高すぎだ．個人は当然として，会社で使うのもきつい．
% 特にWebで使う場合…．EE版１CPU1280万って…

127 ：名無しさん＠お腹いっぱい。 ：2001/02/02(金) 15:32

ＤＢ障害でデータを失うというのは致命的だろ。
だからPostgreSQLは最高さ！！

128 ：名無しさん＠ピンキー ：2001/02/03(土) 00:51

>>127
あ〜ら、せっかくまともな書き込みが出てきたと思ってたのに。
またポスグレ場化の集まりになっちゃうのね（ｗ

129 ：１ ：2001/02/03(土) 01:24

上げてやる。
ありがたく思え！！クソどもめ！！

130 ：名無しさん＠お腹いっぱい。 ：2001/02/06(火) 23:43

>>89
Oracleのバックアップの仕組みがまともじゃないやらほざいていたおにいさんはどこいったの？
たまには罵化がいないとさびしいもんだね。
あげとこう

131 ：89 ：2001/02/07(水) 03:06

>>130
呼んだか?
何時でも煽って、かき回してあげるよ。
だから、なんかネタだせよ。

132 ：ポスグレユーザの声 ：2001/02/07(水) 18:35

>>131
消えれ（ｗ

133 ：名無しさん＠お腹いっぱい。 ：2001/02/07(水) 19:48

オマエモナー>>132

134 ：モトカズ ：2001/02/07(水) 22:14

（質問）
私、下記の様にCGIでPerlインターフェースでPostgreにアクセスするような
プログラムをつくっておる者ですが、

（コーディングイメージ例）
:
use Pg;
$cgi=Pg::connectdb("dbname=ＤＢ名");
:
$result=$cgi->exec(　ＳＱＬ文　);
:

このつなげる際に、ユーザ名やパスワードを指定して、（WWWのﾕｰｻﾞではなく）
特定のユーザとしてＤＢに接続するようなことはできますでしょうか？

ご存知の方、そのコーディングイメージ例等をご教示頂ければ大変助かります。
どなたか詳しい方、お助け願えませんでしょうか？

135 ：名無しさん＠お腹いっぱい。 ：2001/02/07(水) 22:26

君にはプログラマの適性が無いよ。

136 ：モトカズ ：2001/02/07(水) 22:33

>>135
まあまあ、そういわないで、少し急いでおりますので･･

137 ：名無しさん＠お腹いっぱい。 ：2001/02/08(木) 00:08

>>131
あ、場蚊発見！
さらしとこう

138 ：名無しさん＠お腹いっぱい。 ：2001/02/08(木) 02:59

>134

ふつーDBI と DBD でかくのでわ？

139 ：名無しさん＠お腹いっぱい。 ：2001/02/08(木) 09:45

>>137
ネタはどーした?

140 ：???????????????B ：2001/02/08(木) 15:18

>>134
perldoc Pg したか?

141 ：モトカズ ：2001/02/08(木) 17:03

>>134　について
>>140
ご指導ありがとうございます。
私、「perldoc」というものがあることも知りませんでした。
とにかく、perldoc Pg で調べさせて頂いております。

>>138
ご指導ありがとうございます。
只、正直申しますと、私このあたりビギナーでございまして、
「DBI」「DBD」 と言う言葉の意味すらわからないありさまで
ございまして、補足頂けると幸いです。

142 ：名無しさん＠お腹いっぱい。 ：2001/02/08(木) 21:27

>>141
http://member.nifty.ne.jp/hippo2000/perltips/index.htm
だ。
なんとなく
>まあまあ、そういわないで、少し急いでおりますので･･
こういうのはちがうとおもうのですわ

143 ：モトカズ ：2001/02/09(金) 09:55

>>142
ありがとうございます。
さっそく、こちらのほうも参考にさせて頂きます。

144 ：モトカズ ：2001/02/09(金) 13:59

>>134 について
アドバイスして頂いた方、ありがとうございました。
また、DBIのご紹介頂いたこと感謝しております。

結局、perldoc Pg等で調べたところ
$cgi = Pg::connectdb("dbname=ＤＢ名 user=ユーザ名 password=パスワード");
のように記述するだけでＯＫでした。

これだけ調べるのにずいぶんと時間がかかってしまいましたが、
ＤＢ名に大文字があると下記例の様に"　"で囲まないとダメ、らしく、
うまくいかない原因を誤解して長引いておりました。
$cgi = Pg::connectdb("dbname=\"ABC_db\" user=ABC_men password=ABC001");
ＤＢ名を''で囲ったり、一旦変数に置き換えたり、いろいろ試してダメでして、
また、ユーザ名やパスワードは大文字で書けばそのまま大文字が設定できるので、
「dbname=」の部分だけの単純な記述の問題とは思えなかったしだいです。

145 ：やまもと ：2001/02/09(金) 20:16

PostODBC with Japanese Patchでint8型のデータベースに
Access2000からアクセスすると、int8を含むテーブルが
見えません。
どうしたらいいですか？

146 ：名無しさん＠お腹いっぱい。 ：2001/02/10(土) 13:42

MiracleLinux が PostgreSQL のサポートをはじめますね。

147 ：名無しさん＠お腹いっぱい。 ：2001/02/10(土) 15:27

>>145
Access97からだと見えたりしてね。
ODBC-APIつかって直にそのテーブルみても見えなかったら、
ODBCドライバマネージャか、そのパッチがおかしい。

148 ：名無しさん＠お腹いっぱい。 ：2001/02/11(日) 15:50

データベースの勉強がてらにPostgreSQLの本買いました。
その本に書いてあったんだけど、postgreでperl使うには何かモジュールをくみこめって
かいてあるんですが、freebsd の/stand/sysinstallにはありませんでした。
freebsd.orgにて検索してもでてこないし、どうすれば良いんでしょうか。

read.cgi ver5.26+ (01/10/21-)