From yasushi ＠ netyear.net  Thu May  1 01:58:56 2003
From: yasushi ＠ netyear.net (Yasushi Mochizuki)
Date: Thu, 1 May 2003 01:58:56 +0900
Subject: [pgsql-jp: 29752] JDBCの限界？
Message-ID: <029e01c30f39$c9d5f260$0203a8c0@YASUSHI>

バベルネットの望月と申します。

　お客さまのシステムにて、突然、INSERTができなくなり
原因を調査しているのですが、皆様のお知恵をお借りしたく
メールをさせていただきました。

環境：RedHat 7.2J
        Postgres 7.1.3+JDBC

エラーの状況：
あるテーブルに('1', '00000004')という行を追加しようとすると、

・      INSERT INTO OPT_PageViewSetting VALUES ( '1',  '00000004' )

・      sample.edit.ConfPageViewRegist - ERR- SQL実行できません<p>

・      sample.edit.ConfPageViewRegist - SQLException: Unable to fathom
update count INSERT 2173528419 1<br>

・      sample.edit.ConfPageViewRegist - SQLState: null<br>

 ・   sample.edit.ConfPageViewRegist - VendorError:



となっており、fathomエラーというエラーが出るようになりました。
どうもOIDがJavaのint値である2147483647を越えたために
interface\jdbc\org\postgresql\Connection.javaにて、oidをparseIntできずに
Exceptionをスルーしているように感じたのですが、oidの限界点って、21億という
ことなのでしょうか？（というより、そんな大量のデータを作る方が悪い？）

上記の状態でも、psqlからはデータのインサートが可能でした。
http://osb.sra.co.jp/PostgreSQL/FAQ/faq.phpなどを見る限りでは42億まで
１つのテーブルで入るみたいですしぃぃ。。。。

申し訳ありませんが、ご存知の方がおられましたらご教授いただきたく
お願いいたします。

取り急ぎ



From gontakun ＠ fish.co.jp  Thu May  1 09:40:33 2003
From: gontakun ＠ fish.co.jp (Chie.M)
Date: Thu, 01 May 2003 09:40:33 +0900
Subject: [pgsql-jp: 29753] Re: トリガの内容表示
In-Reply-To: <49256D18.004B12A4.00@cd.maruzen.co.jp>
References: <49256D18.004B12A4.00@cd.maruzen.co.jp>
Message-ID: <20030501093854.3A5E.GONTAKUN@fish.co.jp>

おはようございます。Chie.Mです。

> 登録済みtriggerの内容を
> 表示確認するにはどのようにしたら良いのでしょうか？

システムカタログのpg_triggerを使えばいかがでしょう？
詳細はこちらをご覧ください。↓
www.postgresql.jp/document/pg721doc/developer/catalog-pg-trigger.html

----------------------------
Chie.M <gontakun ＠ fish.co.jp>



From iakio ＠ pjam.jpweb.net  Thu May  1 10:17:10 2003
From: iakio ＠ pjam.jpweb.net (ISHIDA Akio)
Date: Thu, 1 May 2003 10:17:10 +0900
Subject: [pgsql-jp: 29754] Re: トリガの内容表示
In-Reply-To: <20030501093854.3A5E.GONTAKUN@fish.co.jp>
References: <49256D18.004B12A4.00@cd.maruzen.co.jp> <20030501093854.3A5E.GONTAKUN@fish.co.jp>
Message-ID: <20030501101710.23E62200.iakio@pjam.jpweb.net>

こんにちは。石田@苫小牧市です。

"Chie.M" <gontakun ＠ fish.co.jp> wrote:
(2003/05/01 09:40)

> おはようございます。Chie.Mです。
> 
> > 登録済みtriggerの内容を
> > 表示確認するにはどのようにしたら良いのでしょうか？
> 
> システムカタログのpg_triggerを使えばいかがでしょう？
> 詳細はこちらをご覧ください。↓
> www.postgresql.jp/document/pg721doc/developer/catalog-pg-trigger.html


それ以外の方法としては、pg_dump したファイルの中身を見れば確認できます。

ちなみに view / rule / index に関しては、
pg_get_viewdef() / pg_get_ruledef() / pg_get_indexdef()
という便利な関数があります。
http://www.postgresql.jp/document/pg721doc/user/functions-misc.html

trigger についても、pg_get_triggerdef() という関数が
開発中のバージョンにははいっているようです。
http://archives.postgresql.org/pgsql-patches/2003-03/msg00066.php

こういった、pg_dump がやっていたことを組み込み関数に移す、
というのは良さそうですね。同じようなものをいろんなところで
実装する必要がなくなるので。

--
ISHIDA Akio<iakio ＠ pjam.jpweb.net>



From ykobayas ＠ cd.maruzen.co.jp  Thu May  1 10:39:53 2003
From: ykobayas ＠ cd.maruzen.co.jp (YUUTA KOBAYASHI)
Date: Thu, 1 May 2003 10:39:53 +0900
Subject: [pgsql-jp: 29755] Re: トリガの内容表示
Message-ID: <49256D19.00096BFE.00@cd.maruzen.co.jp>

おはようございます。こばやしです。

ご連絡ありがとうございます。

functionはpg_procを使って、
SELECT prosrc FROM pg_proc WHERE proname = 'name_of_the_function';
のように問い合わせると、内容まで確認できるのですが、
triggerの場合はpg_triggerを使っても、
内容まで確認できないのですが、やり方がまずいのでしょうか？

triggerがかかっているテーブル名、triggerがキックされる条件、
呼び出すfunction名などを確認したいのです。

テーブル名はtgrelidから探っていくのでしょうか？（どうやって！？）
呼び出すfunction名はtgfoidから探っていくのでしょうか？（どうやって！？）
キックされる条件もtgfoidから探れるのでしょうか？


> > 登録済みtriggerの内容を
> > 表示確認するにはどのようにしたら良いのでしょうか？
>
> システムカタログのpg_triggerを使えばいかがでしょう？
> 詳細はこちらをご覧ください。↓
> www.postgresql.jp/document/pg721doc/developer/catalog-pg-trigger.html
>




From minoru5690 ＠ hotmail.com  Thu May  1 11:12:33 2003
From: minoru5690 ＠ hotmail.com (serdfsdfs fsdf)
Date: Thu, 01 May 2003 11:12:33 +0900
Subject: [pgsql-jp: 29756] C#でのPostgreSQLへの接続方法
Message-ID: <Law11-F52wsR8Qk4hvc0001a9e1@hotmail.com>

初心者的な質問で申し訳ありませんが。
データベースにPostgreSQLを使用してOleDb接続でアクセスすることは可能なので
しょうか？
C#でのPostgreSQLへの接続方法を探してみましたが、見つかりませんでした。
データベースは既にできております。
他のC#の掲示板でも聞いてみたのですが、返答がなく、PostgreSQLのメーリングリス
トで
聞く方が最善だと思われましたので。お聞きしました。
宜しくお願い致します。

OS Windows2000
システム	postgres7.3
ホスト		bsd
テーブル名　f10

_________________________________________________________________
最新のファイナンス情報とライフプランのアドバイス MSN マネー  
http://money.msn.co.jp/  



From hotta ＠ net-newbie.com  Thu May  1 11:33:44 2003
From: hotta ＠ net-newbie.com (HOTTA Michihide)
Date: Thu, 01 May 2003 11:33:44 +0900
Subject: [pgsql-jp: 29757] Re: timestamp を指定しての select
In-Reply-To: <3EABE99C.90005@nifty.ne.jp>
References: <3EABE99C.90005@nifty.ne.jp>
Message-ID: <20030501112703.DFAB.HOTTA@net-newbie.com>

堀田％諫早市から長崎市に引っ越しました、です。

From: Koichi Shimamura <maf01541 ＠ nifty.ne.jp>
Subject: [pgsql-jp: 29734] timestamp を指定しての select
Date: 2003/04/27 23:30:52

> timestamp 型のフィールドに対して次に用に条件指定で select をし
> ても該当なしで返ってきます。
> 
> > my_db=> create table test_table (mydatetime timestamp);
> > CREATE
> > my_db=> insert into test_table (mydatetime) values (now());
> > INSERT 3118382 1
> > my_db=> select * from test_table;
> >           mydatetime
> > -------------------------------
> >  2003-04-27 23:18:00.931834+09
> > (1 row)
> >
> > my_db=> select * from test_table where mydatetime = '2003-04-27
> 23:18:00.931834+09';
> >  mydatetime
> > ------------
> > (0 rows)

手元の環境(7.2.3)では再現できませんでした。
原因を絞り込んでゆくとすれば、たとえば不等号を使って

select * from test_table where mydatetime > '2003-04-27 23:18:00';
select * from test_table where mydatetime > '2003-04-27';

などと条件をゆるくしていき、どこで引っかかっているかを調べること
などが、とりあえずは思いつきます。
-- 
堀田 倫英 <hotta ＠ net-newbie.com> <http://www.net-newbie.com>


From yasushi ＠ netyear.net  Thu May  1 11:18:23 2003
From: yasushi ＠ netyear.net (Yasushi Mochizuki)
Date: Thu, 1 May 2003 11:18:23 +0900
Subject: [pgsql-jp: 29758] Re: JDBCの限界？
References: <029e01c30f39$c9d5f260$0203a8c0@YASUSHI>
Message-ID: <035b01c30f87$f134b230$0203a8c0@YASUSHI>

バベルネットの望月と申します。

　昨晩、お送りさせていただいたメールなのですが、
DB内で定義されたOIDの中で利用していないものを
開放するようなことはできるのでしょうか？

　Webログの分析システムであり、半年以上経過して
「OIDを食いつぶした」ことが原因のようなので、利用していない
OIDを開放し、再利用できればと考えているのですが
如何でしょうか？

取り急ぎ

----- Original Message -----
From: "Yasushi Mochizuki" <yasushi ＠ netyear.net>
To: <pgsql-jp ＠ ml.postgresql.jp>
Sent: Thursday, May 01, 2003 1:58 AM
Subject: [pgsql-jp: 29752] JDBCの限界？


> バベルネットの望月と申します。
>
> 　お客さまのシステムにて、突然、INSERTができなくなり
> 原因を調査しているのですが、皆様のお知恵をお借りしたく
> メールをさせていただきました。
>
> 環境：RedHat 7.2J
>         Postgres 7.1.3+JDBC
>
> エラーの状況：
> あるテーブルに('1', '00000004')という行を追加しようとすると、
>
> ・      INSERT INTO OPT_PageViewSetting VALUES ( '1',  '00000004' )
>
> ・      sample.edit.ConfPageViewRegist - ERR- SQL実行できません<p>
>
> ・      sample.edit.ConfPageViewRegist - SQLException: Unable to fathom
> update count INSERT 2173528419 1<br>
>
> ・      sample.edit.ConfPageViewRegist - SQLState: null<br>
>
>  ・   sample.edit.ConfPageViewRegist - VendorError:
>
>
>
> となっており、fathomエラーというエラーが出るようになりました。
> どうもOIDがJavaのint値である2147483647を越えたために
> interface\jdbc\org\postgresql\Connection.javaにて、oidをparseIntできずに
> Exceptionをスルーしているように感じたのですが、oidの限界点って、21億という
> ことなのでしょうか？（というより、そんな大量のデータを作る方が悪い？）
>
> 上記の状態でも、psqlからはデータのインサートが可能でした。
> http://osb.sra.co.jp/PostgreSQL/FAQ/faq.phpなどを見る限りでは42億まで
> １つのテーブルで入るみたいですしぃぃ。。。。
>
> 申し訳ありませんが、ご存知の方がおられましたらご教授いただきたく
> お願いいたします。
>
> 取り急ぎ
>
>



From hotta ＠ net-newbie.com  Thu May  1 11:47:41 2003
From: hotta ＠ net-newbie.com (HOTTA Michihide)
Date: Thu, 01 May 2003 11:47:41 +0900
Subject: [pgsql-jp: 29759] Re: vacuumdb のオプション(--analzye, --full)の運用時の使い方
In-Reply-To: <004c01c30d5a$155474a0$7b00a8c0@crew.findnet.jp>
References: <004c01c30d5a$155474a0$7b00a8c0@crew.findnet.jp>
Message-ID: <20030501113352.DFAE.HOTTA@net-newbie.com>

堀田です。

From: "kinosita" <kino ＠ deneb.jp>
Subject: [pgsql-jp: 29736] vacuumdb のオプション(--analzye, --full)の運用時の使い方
Date: 2003/04/28 16:45:05

> 仮に、DBNAME というデータベースに、TABLE_A, TABLE_B, TABLE_C
>  というテーブルがあるとします。
> このデータベースに対して、vacuumdb をかけ、オプションに--full と
> --analyze をかけるつもりでいます。
> 
> ここで、
> ・クライアントPCからのリクエストに対する応答速度を最も早くする
>   ことを最大優先課題とする。
> ・CPU の使用率や、計算時間は考慮しない。
> という目的があった場合、下記の (1)〜(3)のどれが最も適しているの
> でしょうか？

識者ではないので質問には答えられませんが、一般的には、どの方法が
一番速い（早い）かという問題は、データベースの使い方や環境に左右
される面が大きいと思われるので、まず「やってみる」ことが先決では
ないでしょうか。

そして、何か自分の予想と異なった結果が出たら、そのことについて質
問してみるとよいかと思います。ただし、その際も出せる限りの情報を
出さないと、フォローがつくのはやはり難しいかもしれません。

# 単に GW だから識者の皆さんがお休みなだけかな…？

> 個人的には(3) をやろうと思っていますが、結果的に(1) と変わらな
> いのであれば、やる意味がないので、質問させてもらいました。

このように書くと、「時間がもったいないから誰か代わりに調べてね」
というようにも取られかねません。気をつけましょう。
-- 
堀田 倫英 <hotta ＠ net-newbie.com> <http://www.net-newbie.com>


From imagawa ＠ okayama-coop.or.jp  Thu May  1 12:03:07 2003
From: imagawa ＠ okayama-coop.or.jp (今川　晃)
Date: Thu, 01 May 2003 12:03:07 +0900
Subject: [pgsql-jp: 29760] Re: JDBCの限界？
In-Reply-To: <035b01c30f87$f134b230$0203a8c0@YASUSHI>
References: <029e01c30f39$c9d5f260$0203a8c0@YASUSHI> <035b01c30f87$f134b230$0203a8c0@YASUSHI>
Message-ID: <20030501120300.A9BF.IMAGAWA@okayama-coop.or.jp>

----------------------------------
おかやまコープ　情報システム部
今川　晃　imagawa ＠ okayama-coop.or.jp




From gontakun ＠ fish.co.jp  Thu May  1 12:07:04 2003
From: gontakun ＠ fish.co.jp (Chie.M)
Date: Thu, 01 May 2003 12:07:04 +0900
Subject: [pgsql-jp: 29761] Re: トリガの内容表示
In-Reply-To: <49256D19.00096BFE.00@cd.maruzen.co.jp>
References: <20030501101710.23E62200.iakio@pjam.jpweb.net> <49256D19.00096BFE.00@cd.maruzen.co.jp>
Message-ID: <20030501114047.3A64.GONTAKUN@fish.co.jp>

Chie.Mです。こんにちは。

> テーブル名はtgrelidから探っていくのでしょうか？（どうやって！？）
> 呼び出すfunction名はtgfoidから探っていくのでしょうか？（どうやって！？）> キックされる条件もtgfoidから探れるのでしょうか？

普通にSQLを発行するのではダメでしょうか？
マニュアルに書いてある条件どおりに組めば、関数名とかテーブル名は
取得できると思います。

私もPostgreSQLは初心者の部類なので、pg_trrigerのテーブルの中身と
マニュアルつき合わせて挑戦してみました。

かなり適当ですが、こんな感じで↓

SELECT
    A.tgname AS トリガ, C.relname AS テーブル名, 
    A.tgtype AS 種類, P.proname AS 関数
FROM
    pg_class AS C INNER JOIN (
        pg_trigger AS B INNER JOIN 
            pg_trigger AS A ON B.tgconstrrelid = A.tgrelid
    ) ON C.oid = B.tgconstrrelid INNER JOIN 
    pg_proc AS P ON A.tgfoid = P.oid
WHERE
    A.tgisconstraint=false
GROUP BY
    A.tgname, C.relname, A.tgtype, P.proname;

# 実際使う場合はもっとましなSQL書いてください^^;
# 他にもっとマシな方法があったら識者の方突っ込んでください・・・。

種類のカラムは「トリガー条件を指定するビットマスク」で
　0x1:ROW、0x2:BEFORE、0x4:INSERT、0x8:DELETE、0x10:UPDATE
ということだそうです。
これはソースコードみないとダメみたいですが、過去ログに出てました。。。

この値を取得したい時は、
　tgtypeの値が7の時は「BERORE INSERT FOR EACHE ROW」
　tgtypeの値が19の時は「BEFORE UPDATE FOR EACH ROW」
などど、関数にでもしておけば、表示も可能だと思います。

用途にもよると思いますが、石田さんの書かれた↓こちらの方法のが
簡単かも知れません。
> それ以外の方法としては、pg_dump したファイルの中身を見れば確認できます

↓これがすごく楽しみですね。
> trigger についても、pg_get_triggerdef() という関数が
> 開発中のバージョンにははいっているようです。
> http://archives.postgresql.org/pgsql-patches/2003-03/msg00066.php

石田さん情報ありがとうございました！(^-^)
----------------------------
Chie.M <gontakun ＠ fish.co.jp>



From imagawa ＠ okayama-coop.or.jp  Thu May  1 12:09:47 2003
From: imagawa ＠ okayama-coop.or.jp (今川　晃)
Date: Thu, 01 May 2003 12:09:47 +0900
Subject: [pgsql-jp: 29762] Re: JDBCの限界？
In-Reply-To: <035b01c30f87$f134b230$0203a8c0@YASUSHI>
References: <029e01c30f39$c9d5f260$0203a8c0@YASUSHI> <035b01c30f87$f134b230$0203a8c0@YASUSHI>
Message-ID: <20030501120325.A9C1.IMAGAWA@okayama-coop.or.jp>

> 「OIDを食いつぶした」ことが原因のようなので、利用していない
一度、テキストにはき出して、COPYで戻したらどうですか？
これで延命できるでしょう。


最前方法は、
OID無しでテーブルを張り直すのが良いと思います。
7.1.3で出来るのかは忘れました。



----------------------------------
おかやまコープ　情報システム部
今川　晃　imagawa ＠ okayama-coop.or.jp




From imagawa ＠ okayama-coop.or.jp  Thu May  1 12:15:37 2003
From: imagawa ＠ okayama-coop.or.jp (今川　晃)
Date: Thu, 01 May 2003 12:15:37 +0900
Subject: [pgsql-jp: 29763] Re: JDBCの限界？
In-Reply-To: <20030501120325.A9C1.IMAGAWA@okayama-coop.or.jp>
References: <035b01c30f87$f134b230$0203a8c0@YASUSHI> <20030501120325.A9C1.IMAGAWA@okayama-coop.or.jp>
Message-ID: <20030501121114.A9C3.IMAGAWA@okayama-coop.or.jp>

> > 「OIDを食いつぶした」ことが原因のようなので、利用していない
> 一度、テキストにはき出して、COPYで戻したらどうですか？
> これで延命できるでしょう。
単純にコピーで戻すだけで、OIDがクリアされるのか？されないのか？
知りませんので、

エクスポート
↓
テーブル再作成
↓
COPYで戻す

が無難のような。


参考程度に。



----------------------------------
おかやまコープ　情報システム部
今川　晃　imagawa ＠ okayama-coop.or.jp




From yutaka ＠ hi-net.zaq.ne.jp  Thu May  1 12:21:07 2003
From: yutaka ＠ hi-net.zaq.ne.jp (Yutaka tanida)
Date: Thu, 01 May 2003 12:21:07 +0900
Subject: [pgsql-jp: 29764] Re: C#でのPostgreSQL への接続方法
In-Reply-To: <Law11-F52wsR8Qk4hvc0001a9e1@hotmail.com>
References: <Law11-F52wsR8Qk4hvc0001a9e1@hotmail.com>
Message-ID: <20030501121611.FC91.YUTAKA@hi-net.zaq.ne.jp>

谷田です。

On Thu, 01 May 2003 11:12:33 +0900
"serdfsdfs fsdf" <minoru5690 ＠ hotmail.com> wrote:

> 初心者的な質問で申し訳ありませんが。
> データベースにPostgreSQLを使用してOleDb接続でアクセスすることは可能なので
> しょうか？
> C#でのPostgreSQLへの接続方法を探してみましたが、見つかりませんでした。

・ODBC経由
・http://gborg.postgresql.org/project/npgsql/projdisplay.php

と言った方法があります。

-- 
Yutaka tanida <yutaka ＠ nonsensecorner.com>
http://www.nonsensecorner.com/



From yiwakiri ＠ st.rim.or.jp  Thu May  1 12:24:07 2003
From: yiwakiri ＠ st.rim.or.jp (Youichi Iwakiri)
Date: Thu, 01 May 2003 12:24:07 +0900
Subject: [pgsql-jp: 29765] Re: JDBCの限界？
In-Reply-To: <20030501120325.A9C1.IMAGAWA@okayama-coop.or.jp>
References: <029e01c30f39$c9d5f260$0203a8c0@YASUSHI>
	<035b01c30f87$f134b230$0203a8c0@YASUSHI>
	<20030501120325.A9C1.IMAGAWA@okayama-coop.or.jp>
Message-ID: <200305010324.MAA21101@mail6.rim.or.jp>

いわきりです

今川　晃 wrote in <20030501121114.A9C3.IMAGAWA ＠ okayama-coop.or.jp> :
>単純にコピーで戻すだけで、OIDがクリアされるのか？されないのか？
>知りませんので、
>エクスポート
>↓
>テーブル再作成
>↓
>COPYで戻す
>
>が無難のような。
>参考程度に。

pg_dump
drop table
pg_restore

ですかね。順序的には。

今川　晃 wrote in <20030501120325.A9C1.IMAGAWA ＠ okayama-coop.or.jp> :
>最前方法は、
>OID無しでテーブルを張り直すのが良いと思います。
>7.1.3で出来るのかは忘れました。

7.2での変更点です。
元のメールを読むかぎり、jdbcドライバは、oidを問い合わせ取得している
様に思えますが、WITHOUT OIDS 指定で作成されたTABLEへのアクセスは
可能なのでしょうか? > 件のjdbcドライバ

-- 
Youichi Iwakiri



From ykobayas ＠ cd.maruzen.co.jp  Thu May  1 12:40:30 2003
From: ykobayas ＠ cd.maruzen.co.jp (YUUTA KOBAYASHI)
Date: Thu, 1 May 2003 12:40:30 +0900
Subject: [pgsql-jp: 29766] Re: トリガの内容表示
Message-ID: <49256D19.00147733.00@cd.maruzen.co.jp>

こばやしです。こんにちは。

Chie.Mさんに教えていただいたSQLで出来ました。
ありがとうございます！

OracleのSchema Managerに慣れちゃうとだめですね。

石田さんに教えていただいた方法も試してみます。

> Chie.Mです。こんにちは。
>
> > テーブル名はtgrelidから探っていくのでしょうか？（どうやって！？）
> > 呼び出すfunction名はtgfoidから探っていくのでしょうか？（どうやって！？
> ）> キックされる条件もtgfoidから探れるのでしょうか？
>
> 普通にSQLを発行するのではダメでしょうか？
> マニュアルに書いてある条件どおりに組めば、関数名とかテーブル名は
> 取得できると思います。
>
> 私もPostgreSQLは初心者の部類なので、pg_trrigerのテーブルの中身と
> マニュアルつき合わせて挑戦してみました。
>
> かなり適当ですが、こんな感じで↓
>
> SELECT
>     A.tgname AS トリガ, C.relname AS テーブル名,
>     A.tgtype AS 種類, P.proname AS 関数
> FROM
>     pg_class AS C INNER JOIN (
>         pg_trigger AS B INNER JOIN
>             pg_trigger AS A ON B.tgconstrrelid = A.tgrelid
>     ) ON C.oid = B.tgconstrrelid INNER JOIN
>     pg_proc AS P ON A.tgfoid = P.oid
> WHERE
>     A.tgisconstraint=false
> GROUP BY
>     A.tgname, C.relname, A.tgtype, P.proname;
>
> # 実際使う場合はもっとましなSQL書いてください^^;
> # 他にもっとマシな方法があったら識者の方突っ込んでください・・・。
>
> 種類のカラムは「トリガー条件を指定するビットマスク」で
> 　0x1:ROW、0x2:BEFORE、0x4:INSERT、0x8:DELETE、0x10:UPDATE
> ということだそうです。
> これはソースコードみないとダメみたいですが、過去ログに出てました。。。
>
> この値を取得したい時は、
> 　tgtypeの値が7の時は「BERORE INSERT FOR EACHE ROW」
> 　tgtypeの値が19の時は「BEFORE UPDATE FOR EACH ROW」
> などど、関数にでもしておけば、表示も可能だと思います。
>
> 用途にもよると思いますが、石田さんの書かれた↓こちらの方法のが
> 簡単かも知れません。
> > それ以外の方法としては、pg_dump したファイルの中身を見れば確認できます
>
> ↓これがすごく楽しみですね。
> > trigger についても、pg_get_triggerdef() という関数が
> > 開発中のバージョンにははいっているようです。
> > http://archives.postgresql.org/pgsql-patches/2003-03/msg00066.php
>
> 石田さん情報ありがとうございました！(^-^)
> ----------------------------
> Chie.M <gontakun ＠ fish.co.jp>
>




From yasushi ＠ netyear.net  Thu May  1 12:21:03 2003
From: yasushi ＠ netyear.net (Yasushi Mochizuki)
Date: Thu, 1 May 2003 12:21:03 +0900
Subject: [pgsql-jp: 29767] Re: JDBCの限界？
References: <029e01c30f39$c9d5f260$0203a8c0@YASUSHI><035b01c30f87$f134b230$0203a8c0@YASUSHI><20030501120325.A9C1.IMAGAWA@okayama-coop.or.jp> <200305010324.MAA21101@mail6.rim.or.jp>
Message-ID: <041b01c30f90$b2581490$0203a8c0@YASUSHI>

望月＠バベルネットです。

　今川さん、いわきりさん、早速のリプライをありがとうございました。

----- Original Message -----
Sent: Thursday, May 01, 2003 12:24 PM
Subject: [pgsql-jp: 29765] Re: JDBCの限界？


> 今川　晃 wrote in <20030501121114.A9C3.IMAGAWA ＠ okayama-coop.or.jp> :
> >単純にコピーで戻すだけで、OIDがクリアされるのか？されないのか？
> >知りませんので、
> >エクスポート
> >↓
> >テーブル再作成
> >↓
> >COPYで戻す
> >
> >が無難のような。
> >参考程度に。
>
> pg_dump
> drop table
> pg_restore
>
> ですかね。順序的には。

　ありがとうございます。テストをしてみます。

> 今川　晃 wrote in <20030501120325.A9C1.IMAGAWA ＠ okayama-coop.or.jp> :
> >最前方法は、
> >OID無しでテーブルを張り直すのが良いと思います。
> >7.1.3で出来るのかは忘れました。
>
> 7.2での変更点です。
> 元のメールを読むかぎり、jdbcドライバは、oidを問い合わせ取得している
> 様に思えますが、WITHOUT OIDS 指定で作成されたTABLEへのアクセスは
> 可能なのでしょうか? > 件のjdbcドライバ

　う〜ん、、、バックエンドからの返事を受けて、JDBCドライバの中で
ResultSetクラスをNewする際に、OIDなどのデータを使っているらしいのですが
7.1.3では、intの大きさで使うことを前提にコーディングされている感じでした。
7.2.3の付属JDBCですと、OIDの部分はlong型になっていますし、完全に別な
設計になっているようでした。

取り急ぎ



From jsibasaki ＠ luftwaffe.zive.net  Thu May  1 13:27:24 2003
From: jsibasaki ＠ luftwaffe.zive.net (js)
Date: Thu, 1 May 2003 13:27:24 +0900
Subject: [pgsql-jp: 29768] Re: C#でのPostgreSQL への接続方法
References: <Law11-F52wsR8Qk4hvc0001a9e1@hotmail.com>
Message-ID: <001301c30f99$f7447ea0$3401a8c0@WS80>

----- Original Message -----
From: "serdfsdfs fsdf" <minoru5690 ＠ hotmail.com>
To: <pgsql-jp ＠ ml.postgresql.jp>
Sent: Thursday, May 01, 2003 11:12 AM
Subject: [pgsql-jp: 29756] C#でのPostgreSQL への接続方法


> 初心者的な質問で申し訳ありませんが。
> データベースにPostgreSQLを使用してOleDb接続でアクセスすることは可能なので
> しょうか？
> C#でのPostgreSQLへの接続方法を探してみましたが、見つかりませんでした。
> データベースは既にできております。
> 他のC#の掲示板でも聞いてみたのですが、返答がなく、PostgreSQLのメーリングリ
ス
> トで
> 聞く方が最善だと思われましたので。お聞きしました。
> 宜しくお願い致します。
>
> OS Windows2000
> システム postgres7.3
> ホスト bsd
> テーブル名　f10
>
> _________________________________________________________________


こんにちわ。自分もC#をはじめてみたいと思っているのですが
Windows版PostGresのPowerGresのトライアル版に libpq.dll というライブラリが付
属していましたが
これを使ってC#でデータベースに接続するサンプルがもしあれば教えて頂けないで
しょうか？










From MAF01541 ＠ nifty.ne.jp  Thu May  1 13:32:33 2003
From: MAF01541 ＠ nifty.ne.jp (島村　幸一)
Date: Thu,  1 May 2003 13:32:33 +0900
Subject: [pgsql-jp: 29769] Re: timestamp を指
In-Reply-To: <20030501112703.DFAB.HOTTA@net-newbie.com>
References: <3EABE99C.90005@nifty.ne.jp>
	<20030501112703.DFAB.HOTTA@net-newbie.com>
Message-ID: <20030501133233.3f6c0605.03717@nifty.ne.jp>

島村です。

> select * from test_table where mydatetime > '2003-04-27 23:18:00';
> select * from test_table where mydatetime > '2003-04-27';
> 
> などと条件をゆるくしていき、どこで引っかかっているかを調べること
> などが、とりあえずは思いつきます。

こういう風に探すんですね。ちょっと頭が固くなっていました。

で、考えたんですが、データベース内ではもっと細かい数字で管理しているんだけど、
表現上「秒」の下６桁までしか表示しない。だからこの値を = で探そうとしても見つ
からない、と。あってますでしょうか？

不等号や between を組み合わせての検索にしてみようと思います。

ありがとうございました。

島村幸一
http://www.bekkoame.ne.jp/~joe90/


From iakio ＠ pjam.jpweb.net  Thu May  1 18:47:44 2003
From: iakio ＠ pjam.jpweb.net (ISHIDA Akio)
Date: Thu, 1 May 2003 18:47:44 +0900
Subject: [pgsql-jp: 29770] Re: vacuumdb のオプション(--analzye, --full)の運用時の使い方
In-Reply-To: <20030501113352.DFAE.HOTTA@net-newbie.com>
References: <004c01c30d5a$155474a0$7b00a8c0@crew.findnet.jp> <20030501113352.DFAE.HOTTA@net-newbie.com>
Message-ID: <20030501184744.A448D280.iakio@pjam.jpweb.net>

こんにちは。石田@苫小牧市です。

HOTTA Michihide <hotta ＠ net-newbie.com> wrote:
(2003/05/01 11:47)

> 堀田です。
> 
> From: "kinosita" <kino ＠ deneb.jp>
> Subject: [pgsql-jp: 29736] vacuumdb のオプション(--analzye, --full)の運用時の使い方
> Date: 2003/04/28 16:45:05
> 
> > 仮に、DBNAME というデータベースに、TABLE_A, TABLE_B, TABLE_C
> >  というテーブルがあるとします。
> > このデータベースに対して、vacuumdb をかけ、オプションに--full と
> > --analyze をかけるつもりでいます。
> > 
> > ここで、
> > ・クライアントPCからのリクエストに対する応答速度を最も早くする
> >   ことを最大優先課題とする。
> > ・CPU の使用率や、計算時間は考慮しない。
> > という目的があった場合、下記の (1)〜(3)のどれが最も適しているの
> > でしょうか？
> 
> 識者ではないので質問には答えられませんが、一般的には、どの方法が
> 一番速い（早い）かという問題は、データベースの使い方や環境に左右
> される面が大きいと思われるので、まず「やってみる」ことが先決では
> ないでしょうか。
> 
> そして、何か自分の予想と異なった結果が出たら、そのことについて質
> 問してみるとよいかと思います。ただし、その際も出せる限りの情報を
> 出さないと、フォローがつくのはやはり難しいかもしれません。

vaccum 自体が速く終了することも大切かもしれませんが、
vaccum が適切なタイミングで行なわれることも重要です。
そのタイミングも、データベースにどのようなデータが
格納されるかに左右されるので、やはり「やってみる」ことでしか
良い解はえられないでしょう。

一般的には、--analyze も --full もつけない vacuum を
頻繁に行ない、--analyze や --full はたまに行なうようです。

contrib/pgstattuple を定期的に実行して、
tuple_percent が極端に減ってしまわないタイミングで vacuum 
を行なうのが良いでしょう。
以前は 1 時間に 1 度 vacuum するという例もありました。
場合によってやもっとやっても良いと思います。

vacuum の定期的な実行によってテーブルのサイズが増えてしまうの
をうまく防止できれば、結果として --analyze や --full の
実行速度も速くなるはずです。

--
ISHIDA Akio<iakio ＠ pjam.jpweb.net>



From atushi.yamamoto ＠ toshiba-tsys.co.jp  Fri May  2 09:50:16 2003
From: atushi.yamamoto ＠ toshiba-tsys.co.jp (山本)
Date: Fri, 2 May 2003 09:50:16 +0900
Subject: [pgsql-jp: 29771] OracleからPostgreSQLに移行時の性能劣化
Message-ID: <006001c31044$cd12d590$4e20a8c0@AYAMAMOTO>

こんにちは。山本です。


以前みなさんから新規発言を返信でしないで下さいと御指摘いただいて
最初はわからなかったのですが、スレッドを見て理解致しました。
大変失礼致しました。

ここで本題に入るのですが、
今現在プログラム移行をしています。
ハードの性能は上がり、ソースは移植にも関わらず
性能が劣化してしまっています。
OracleからLinuxへ移行するには
ソース移植だけでは駄目で、
何か修正する必要があるのでしょうか？


OS　　：Solaris2.5.1　→　RedHatLinux7.3
DB　　：Oracle7 　　　→　PostgreSQL7.2.1
HW　　：AS7000　　　　→　Magnia Lite21
データ：44万件
言語　：C言語でEXEC SQLを使用



From matsumurah ＠ citizen.co.jp  Fri May  2 10:05:55 2003
From: matsumurah ＠ citizen.co.jp (Hirokazu Matsumura)
Date: Fri, 2 May 2003 10:05:55 +0900
Subject: [pgsql-jp: 29772] Re: substring を使用した場合の検索結果について
Message-ID: <OF478637E2.9E00C2FF-ON49256D1A.00037EDA@citizen.co.jp>

皆様おはようございます。松村です。
仲村様、油井様返答有難う御座いました（＾＾）

> この場合は取り敢えず, 関数インデックスを使わなければならないと思いま
す.
> http://developer.postgresql.org/docs/postgres/indexes-functional.html
>
> コストの見積もりが,
> cost=0.00..1191.36 rows=108 width=238
> に対して, 実際の結果が
> actual time=175.69..345.42 rows=1 loops=1
> となっていますが, 統計情報の更新(analyze)は行ないましたか?
> #SET STATISTICS xxして, より詳細な統計と取ったりもできます..
>
> 確か結構前のバージョンからか, vacuumとanalyzeは別になったとか聞いたよ
うな
> あと, vacuumも単にvacuumでなくて, _一度_, vacuum full(排他的ロックが
かか
> ります)すると
> 物理的に縮小される(ケースもある)ので, 微妙に早くなるかも知れません.

関数インデックスを以下のようにして作成してみました。
１．create index col2_substr on test1 (substring(cols,1,3))
parse errorで怒られてしまいました（＾＾；

又、--analizeや--full等を試みてみましたが、今回はこちらも変化が無いよう
に思いました。
今回は時間も無く仕方が無いので、テーブルに項目を１つ追加してインデック
スを付加し、
substringを使用しないように致しました。

私としても、「関数インデックス」がポイントになりそうな気がするので
時間の有る時に引き続き調べてみようと思います。
どうも有難う御座いました！

----------------------------------------------
松村 浩一
----------------------------------------------



From pgsql ＠ e-linez.com  Fri May  2 10:32:32 2003
From: pgsql ＠ e-linez.com (Masato Tanaka)
Date: Fri, 2 May 2003 10:32:32 +0900
Subject: [pgsql-jp: 29773] Unable to convert date to tm
Message-ID: <007801c3104a$b3f1f9f0$4dedd8ca@e1>

こんにちは。田中と申します。

Postgres7.2.1で困っています。

日付型のフィールドに、特定の日付が入っていると、TIMESTAMPで値を取得できず、
 ERROR:  Unable to convert date to tm
というメッセージが出てしまいます。

現状ですが、以下のような、birthday という日付型のフィールドがあるのですが、
birthdayの値によって年齢を取得するSQLがエラーになってしまいます。

[table]
 id  | birthday
-----|------------
 1   | 1948-04-05
 2   | 1976-06-07

●成功パターン
=> SELECT extract(year from age(birthday::TIMESTAMP)) as age from table
where id='2';
 age
-----
  26

●失敗パターン
=> SELECT extract(year from age(birthday::TIMESTAMP)) as age from table
where id='1';
ERROR:  Unable to convert date to tm


何かわかりましたら、アドバイスいただけると嬉しいです。




From shiina.yasutada ＠ tohoku.ns-sol.co.jp  Fri May  2 10:40:13 2003
From: shiina.yasutada ＠ tohoku.ns-sol.co.jp (椎名　靖忠)
Date: Fri, 2 May 2003 10:40:13 +0900
Subject: [pgsql-jp: 29774] Re: MSProject2000とPostgreSQL7.2.1
Message-ID: <003001c3104b$c6f2d320$8efc1cac@YSHIINA>

椎名です。
お世話になります。

加藤＠川崎様、アドバイスありがとうございました。

MS-Project2000用DB環境作成スクリプトの件は、
スクリプト後半のcreate文でerrorが出ていない事を
確認し、正常終了としています。

現時点での接続要件が

　　RedHat Linux8.0
　　MS-Projects Standard 2002
　　ODBC 7.01.00.06
　　PostgreSQL 7.2.2

であるため、MS-Project2000の初期環境を使用して、
MS-Project2002でデータ保存が可能かテストしたところ、
以下のエラーとなっております。

-----------以下、エラー内容------------
 SQLExecDirect  with return code -1 (SQL_ERROR)
  HSTMT               055516A0
  UCHAR *             0x0011E790 [      52]
"select PROJ_TYPE from MSP_PROJECTS where PROJ_ID = 0"
  SDWORD                    52

DIAG [S1000] Error while executing the query;
ERROR:  Attribute 'proj_type' not found (7)

SQLExecDirect  with return code -1 (SQL_ERROR)
  HSTMT               055516A0
  UCHAR *             0x00130178
  SDWORD                     0

 DIAG [S1090] [Microsoft][ODBC Driver Manager]
 文字列またはバッファの長さが無効です。 (0)

SQLExecDirect  with return code -1 (SQL_ERROR)
  HSTMT               055516A0
  UCHAR *             0x00000000
  SDWORD                     0

DIAG [S1009] [Microsoft][ODBC Driver Manager]
引数の値が無効です。 (0)

以降、何回も引数エラーの繰り返し

-----------以上、エラー内容------------

エラーを確認すると、MS-Project2000とは動作仕様が異なり、
MS-Project2002で必要とする属性やデータ長でなかったり、引数のやり取りで
エラーが発生していると推測しています。

また、MS-Project2000用のDB環境作成スクリプトを確認すると、
TBL作成の他、function、type等必要な機能を作成する事が
使用前提となっているようです。

MS-Project2002用のDB環境作成スクリプトが存在しない点から考えると
上記接続要件でのMSProject2002とPostgerSQLのODBC接続実績
はないのでしょうか？

もし、実績があれば接続環境等教えて頂きたく。

知見者の方、ご回答やアドバイス
宜しくお願いいたします。



From ono ＠ fjct.fujitsu.com  Fri May  2 10:44:29 2003
From: ono ＠ fjct.fujitsu.com (Kenji ono)
Date: Fri, 2 May 2003 10:44:29 +0900
Subject: [pgsql-jp: 29775] Re: OracleからPostgreSQLに移行時の性能劣化
In-Reply-To: <006001c31044$cd12d590$4e20a8c0@AYAMAMOTO>
References: <006001c31044$cd12d590$4e20a8c0@AYAMAMOTO>
Message-ID: <200305021044.EJD70934.PPO@fjct.fujitsu.com>

こんにちは、山本さん。小野といいます。

言葉の趣旨がいまいちなんですが・・・。
Ｌｉｎｕｘへの移行がどうのではなく、OracleとPostgreSQLでは
処理速度が落ちた、と言いたいのでしょうか。
システムでコーディングしているSQLがあって、それをEXPLANを
かけたらOracleで１０秒がPostgreSQLで１分かかります、と言った
苦情をいっているのでしょうか。

RDBMSの種類によって、得意な処理がありますので、それにあった
SQLを組むのが得策かと。
まずは、どのようなSQLを組んだら劣化するのかサンプルをアップ
してはいかがでしょうか。

どうせなら、PostgreSQLは7.2.1ではなく、7.3.2のほうが性能が
良いのかな。


> Subject : [pgsql-jp: 29771] OracleからPostgreSQLに移行時の性能劣化
> From : "山本" <atushi.yamamoto ＠ toshiba-tsys.co.jp>
> Date : Fri, 2 May 2003 09:50:16 +0900
> 
> こんにちは。山本です。
> 
> 
> 以前みなさんから新規発言を返信でしないで下さいと御指摘いただいて
> 最初はわからなかったのですが、スレッドを見て理解致しました。
> 大変失礼致しました。
> 
> ここで本題に入るのですが、
> 今現在プログラム移行をしています。
> ハードの性能は上がり、ソースは移植にも関わらず
> 性能が劣化してしまっています。
> OracleからLinuxへ移行するには
> ソース移植だけでは駄目で、
> 何か修正する必要があるのでしょうか？
> 
> 
> OS　　：Solaris2.5.1　→　RedHatLinux7.3
> DB　　：Oracle7 　　　→　PostgreSQL7.2.1
> HW　　：AS7000　　　　→　Magnia Lite21
> データ：44万件
> 言語　：C言語でEXEC SQLを使用
> 

--
富士通キャドテック（株）コーポレートシス事）ＩＢＳ
小野　健二（Kenji ono）
電話：内7195-3824 / 外045-470-1085
メール：ono ＠ fjct.fujitsu.com


From bok ＠ bbsbrain.ne.jp  Fri May  2 10:57:23 2003
From: bok ＠ bbsbrain.ne.jp (keios)
Date: Fri, 2 May 2003 10:57:23 +0900(JST)
Subject: [pgsql-jp: 29776] Re: OracleからPostgreSQL に移行時の性能劣化
In-Reply-To: <006001c31044$cd12d590$4e20a8c0@AYAMAMOTO>
References: <006001c31044$cd12d590$4e20a8c0@AYAMAMOTO>
Message-ID: <20030502105723.44bf.bok@bbsbrain.ne.jp>

このメールは
  "山本" <atushi.yamamoto ＠ toshiba-tsys.co.jp>
さんのメールに対する返信です。

ども井上です。

> 今現在プログラム移行をしています。
> ハードの性能は上がり、ソースは移植にも関わらず
> 性能が劣化してしまっています。
> OS　　：Solaris2.5.1　→　RedHatLinux7.3
> DB　　：Oracle7 　　　→　PostgreSQL7.2.1
> HW　　：AS7000　　　　→　Magnia Lite21

えっと〜まずこれだけでは、ぜんぜん分かりません。
まず条件によっては、同じハードを使ってもソフトウェアによっては、
全然違った性能が出るということ。さらに違うアーキテクチャのマシン
では、同じ性能が出るわけがないと言う問題があると思います。
さらに細かい所を突っ込むと、オラクルで性能が非常に良いDBが、PostgresSQLで最高の性能が出るとは限らないという問題があると
思います。

まあ本音言うとそれよりかは、AS7000のストレージがhardwareRAID
組んでてMagnia Lite21の方は、SoftWareRAIDとか、搭載メモリの量
が少ないとかでI/O性能の差があるんじゃ無いかな〜とか、PostgreSQL
の設定のチューニングが甘いとかその辺で差が付いてるんじゃないかな
って思ってるんですが。

#あとそれは書いて無いので憶測ですがAS7000よりクロック周波数は、
#早い(アーキテクチャ違うから比べる意味無いんですけど)CPUを２個
#積んでるのだからとお考えの場合だと、PostgreSQLは、まだうまく
#分散処理ができなかったような記憶があるのですが
#どうでしたっけ？>誰か偉い人教えて〜

この場合は、そのあたりも踏まえて、もう一度設計を見直してみて
はいかがでしょうか？
それともどうすれば、PostgreSQLの性能を上げるチューニングが行える
かとかに、質問を変えたほうがよりいい気がします。

#私も興味があるので聞きたいんですけど。

By Yoshihisa Inoue

By Yoshihisa Inoue


From atushi.yamamoto ＠ toshiba-tsys.co.jp  Fri May  2 11:28:57 2003
From: atushi.yamamoto ＠ toshiba-tsys.co.jp (山本敦)
Date: Fri, 2 May 2003 11:28:57 +0900
Subject: [pgsql-jp: 29777] Re: OracleからPostgreSQL  に移行時の性能劣化
References: <006001c31044$cd12d590$4e20a8c0@AYAMAMOTO> <20030502105723.44bf.bok@bbsbrain.ne.jp>
Message-ID: <009801c31052$95fe0080$4e20a8c0@AYAMAMOTO>

こんんちは山本です。

小野さん、井上さんありがとうございます。

自力でSQLの調査・修正を行ってみます。
DB設計は変更する事ができないのですが、
今後の為にも勉強し、I/O性能、分散処理等を
調べておこうと思います。
つたない文章と非常に少ない情報で
ここまでの回答を貰えてありがたいです。
また何かあれば宜しくお願いします。


----- Original Message ----- 
From: "keios" <bok ＠ bbsbrain.ne.jp>
To: <pgsql-jp ＠ ml.postgresql.jp>
Sent: Friday, May 02, 2003 10:57 AM
Subject: [pgsql-jp: 29776] Re: OracleからPostgreSQL に移行時の性能劣化


> このメールは
>   "山本" <atushi.yamamoto ＠ toshiba-tsys.co.jp>
> さんのメールに対する返信です。
>
> ども井上です。
>
> > 今現在プログラム移行をしています。
> > ハードの性能は上がり、ソースは移植にも関わらず
> > 性能が劣化してしまっています。
> > OS　　：Solaris2.5.1　→　RedHatLinux7.3
> > DB　　：Oracle7 　　　→　PostgreSQL7.2.1
> > HW　　：AS7000　　　　→　Magnia Lite21
>
> えっと〜まずこれだけでは、ぜんぜん分かりません。
> まず条件によっては、同じハードを使ってもソフトウェアによっては、
> 全然違った性能が出るということ。さらに違うアーキテクチャのマシン
> では、同じ性能が出るわけがないと言う問題があると思います。
> さらに細かい所を突っ込むと、オラクルで性能が非常に良いDBが、PostgresSQLで
最高の性能が出るとは限らないという問題があると
> 思います。
>
> まあ本音言うとそれよりかは、AS7000のストレージがhardwareRAID
> 組んでてMagnia Lite21の方は、SoftWareRAIDとか、搭載メモリの量
> が少ないとかでI/O性能の差があるんじゃ無いかな〜とか、PostgreSQL
> の設定のチューニングが甘いとかその辺で差が付いてるんじゃないかな
> って思ってるんですが。
>
> #あとそれは書いて無いので憶測ですがAS7000よりクロック周波数は、
> #早い(アーキテクチャ違うから比べる意味無いんですけど)CPUを２個
> #積んでるのだからとお考えの場合だと、PostgreSQLは、まだうまく
> #分散処理ができなかったような記憶があるのですが
> #どうでしたっけ？>誰か偉い人教えて〜
>
> この場合は、そのあたりも踏まえて、もう一度設計を見直してみて
> はいかがでしょうか？
> それともどうすれば、PostgreSQLの性能を上げるチューニングが行える
> かとかに、質問を変えたほうがよりいい気がします。
>
> #私も興味があるので聞きたいんですけど。
>
> By Yoshihisa Inoue
>
> By Yoshihisa Inoue
>



From hikeda ＠ miraclelinux.com  Fri May  2 11:30:23 2003
From: hikeda ＠ miraclelinux.com (池田　秀一)
Date: Fri, 02 May 2003 11:30:23 +0900
Subject: [pgsql-jp: 29778] Re: OracleからPostgreSQL に移行時の性能劣化
In-Reply-To: <006001c31044$cd12d590$4e20a8c0@AYAMAMOTO>
References: <006001c31044$cd12d590$4e20a8c0@AYAMAMOTO>
Message-ID: <20030502111712.CE18.HIKEDA@miraclelinux.com>

池田です。

> 今現在プログラム移行をしています。
> ハードの性能は上がり、ソースは移植にも関わらず
> 性能が劣化してしまっています。

　「ハードウェア性能は上がり」と書いていますが、提供されて
いる情報では、本当にそうなのかが不明です。
　特に DBMS では、周辺 I/O（ディスク等）の性能が大きく影響
しますので、その点での情報が必要です。
　また、Client/Server 型システムであれば、ネットワーク機材
の影響も受けますので、その点も確認が必要です。

> OracleからLinuxへ移行するには
> ソース移植だけでは駄目で、
> 何か修正する必要があるのでしょうか？

　文章として、「Oracle から Linux へ移行」と言うのは、妙な
表現です。「Solaris から Linux への移行」と言うのと「Oracle
 から PostgreSQL への移行」と、さらには「SPARC CPU から IA
(Intel Architecture) CPU への移行」と３つをまとめて行ってい
る点を十分に意識すべきです。


　余裕があるのであれば、

・「Solaris 上で Oracle から PostgreSQL への移行」
・「Oracle のままで、Linux 上へ移行する」

を行って情報を収集しないと、どこが問題（原因）なのかの切り
分けもできません。
技術者であれば、切り分けを行い易いよういして、問題点を局所
化して、絞りこみ解決を行う方法をしましょう。

# で、私は技術者じゃありません f(^^;) 

個人的な感覚では、ディスクなどの I/O 周辺装置を同等条件に
して比較すると、CPU の Hz 数に性能が比例する傾向があるのは
Oracle だろうと PostgreSQL だろう RDBMS では出ていると認識
しています。
ですから、CPU 数が同じで、800MHz と 1.6GHz であれば、同じ
DBMS で比較すれば、1.6GHz の CPUの方が倍近く早いと思います
けどね。違う DBMS を比較すると、また別問題になりますね。

実際のテスト情報は、仕事上で持っていますが、Oracle 製品の
ライセンス規約に触れる可能性があるので、公開の場所では書け
ないのが残念なところです（苦笑）。

ではでは。
-- -- -- -- -- -- -- -- 
池田　秀一 <ikeda ＠ miraclelinux.com>    Hidekazu Ikeda  
 Sales Division, Business Development,  Director 
　TEL: 03-5562-8310  Fax: 03-5562-8306 
----------  
Oracle9i Database Linux版キャンペーン　 2003/9/30迄
--★MIRACLE LINUX お知らせ★-----------------------
申┃込┃受┃付┃中┃MIRACLE LINUX プロダクトサポート
━┛━┛━┛━┛━┛〜品質向上計画　発動中！！〜　　
http://www.miraclelinux.co.jp/support/product.html
----------------------------------------------------------------------



From pgsql ＠ e-linez.com  Fri May  2 11:30:52 2003
From: pgsql ＠ e-linez.com (Masato Tanaka)
Date: Fri, 2 May 2003 11:30:52 +0900
Subject: [pgsql-jp: 29779] Re: Unable to convert date to tm
References: <007801c3104a$b3f1f9f0$4dedd8ca@e1>
Message-ID: <001301c31052$da20a100$4dedd8ca@e1>

書き忘れておりました。
OSはRedhat Linux7.3です。

> こんにちは。田中と申します。
>
> Postgres7.2.1で困っています。
>
> 日付型のフィールドに、特定の日付が入っていると、TIMESTAMPで値を取得でき
ず、
>  ERROR:  Unable to convert date to tm
> というメッセージが出てしまいます。
>
> 現状ですが、以下のような、birthday という日付型のフィールドがあるのです
が、
> birthdayの値によって年齢を取得するSQLがエラーになってしまいます。
>
> [table]
>  id  | birthday
> -----|------------
>  1   | 1948-04-05
>  2   | 1976-06-07
>
> ●成功パターン
> => SELECT extract(year from age(birthday::TIMESTAMP)) as age from table
> where id='2';
>  age
> -----
>   26
>
> ●失敗パターン
> => SELECT extract(year from age(birthday::TIMESTAMP)) as age from table
> where id='1';
> ERROR:  Unable to convert date to tm
>
>
> 何かわかりましたら、アドバイスいただけると嬉しいです。




From daisaito ＠ lares.dti.ne.jp  Fri May  2 11:38:22 2003
From: daisaito ＠ lares.dti.ne.jp (SAITO Masaru)
Date: Fri, 02 May 2003 11:38:22 +0900
Subject: [pgsql-jp: 29780] Re: OracleからPostgreSQL に移行時の性能劣化
In-Reply-To: <006001c31044$cd12d590$4e20a8c0@AYAMAMOTO>
References: <006001c31044$cd12d590$4e20a8c0@AYAMAMOTO>
Message-ID: <20030502113508.B504.DAISAITO@lares.dti.ne.jp>

齋藤＠横浜です。

202003/05/02 9:50:16 ごろ
"山本" <atushi.yamamoto ＠ toshiba-tsys.co.jp> さんは以下のように書きました

> 今現在プログラム移行をしています。
> ハードの性能は上がり、ソースは移植にも関わらず
> 性能が劣化してしまっています。
> OracleからLinuxへ移行するには
> ソース移植だけでは駄目で、
> 何か修正する必要があるのでしょうか？
> 
> 
> OS　　：Solaris2.5.1　→　RedHatLinux7.3
> DB　　：Oracle7 　　　→　PostgreSQL7.2.1
> HW　　：AS7000　　　　→　Magnia Lite21
> データ：44万件
> 言語　：C言語でEXEC SQLを使用

データの移行はどのようにして行いましたか？
その際に元々のテーブルに付いていたindexなども張り直しましたか？


---
SAITO Masaru <daisaito ＠ lares.dti.ne.jp>



From yu-kishimoto ＠ saturin.co.jp  Fri May  2 12:14:04 2003
From: yu-kishimoto ＠ saturin.co.jp (Kishimoto Yuu)
Date: Fri, 2 May 2003 12:14:04 +0900
Subject: [pgsql-jp: 29781] Re: Unable to convert date to tm
In-Reply-To: <001301c31052$da20a100$4dedd8ca@e1>
References: <007801c3104a$b3f1f9f0$4dedd8ca@e1> <001301c31052$da20a100$4dedd8ca@e1>
Message-ID: <200305021214.04062.yu-kishimoto@saturin.co.jp>

こんにちは、Kishimoto と申します。

金曜日 02 5月 2003 11:30、Masato Tanaka さんは書きました:

> 書き忘れておりました。
> OSはRedhat Linux7.3です。
>
> > こんにちは。田中と申します。
> >
> > Postgres7.2.1で困っています。
> >
> > 日付型のフィールドに、特定の日付が入っていると、TIMESTAMPで値を取得でき
>
> ず、
>
> >  ERROR:  Unable to convert date to tm
> > というメッセージが出てしまいます。

http://www.jp.redhat.com/support/errata/RHSA/RHSA-2003-001J.html より

|This update also contains fixes for several other PostgreSQL bugs,
|including handling of pre-1970 date values in newer versions of glibc,
|possible server shutdown hangs, spinlock hangs on SMP PPC machines, and
|pg_dump improperly dumping with the FULL JOIN USING clauses

と、あります。glibc の最新バージョンにおける PostgreSQL のバグのようです。
上記 URL にあるアップデートパッケージを適用することで、解決できるのでは
ないでしょうか?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Kishimoto Yuu <yu-kishimoto ＠ saturin.co.jp>


From aguri ＠ ssl.fujitsu.com  Fri May  2 12:54:53 2003
From: aguri ＠ ssl.fujitsu.com (Ken-ichi Nakayama)
Date: Fri, 02 May 2003 12:54:53 +0900
Subject: [pgsql-jp: 29782] Re: OracleからPostgreSQL  に移行時の性能劣化
In-Reply-To: <20030502105723.44bf.bok@bbsbrain.ne.jp>
References: <006001c31044$cd12d590$4e20a8c0@AYAMAMOTO> <20030502105723.44bf.bok@bbsbrain.ne.jp>
Message-ID: <20030502124521.8605.AGURI@ssl.fujitsu.com>

なかやまといいます。

On Fri, 2 May 2003 10:57:23 +0900(JST)
keios <bok ＠ bbsbrain.ne.jp> wrote:
bok> このメールは
bok>   "山本" <atushi.yamamoto ＠ toshiba-tsys.co.jp>
bok> さんのメールに対する返信です。
bok> まあ本音言うとそれよりかは、AS7000のストレージがhardwareRAID
bok> 組んでてMagnia Lite21の方は、SoftWareRAIDとか、搭載メモリの量
bok> が少ないとかでI/O性能の差があるんじゃ無いかな〜とか、PostgreSQL
bok> の設定のチューニングが甘いとかその辺で差が付いてるんじゃないかな
bok> って思ってるんですが。

わたしもそのへんじゃないかなと思います。ハードRAIDなら
ディスクアレイ装置が自前で持っているキャッシュ性能とかも
影響していると思いますね。
あと、バス性能ですね。CPU、I/O装置、メモリと個々のスペックで
勝っている新機種よりも、旧機種の性能が良いときはそちらを疑ったり
します。つなぎの部分が悪いとすべて台無しですから。
F1のエンジン積んでいて、シャシーが軽自動車みたいな構成だったりして。
そんなときにはPostgreSQLに限らず、Oracle <-> Oracle の比較でも
そのぐらいの差はでると思います。

-- 
中山 賢一   <E-Mai> aguri ＠ ssl.fujitsu.com <Web> http://www.ssl.fujitsu.com 
株式会社富士通ソーシアルサイエンスラボラトリ ビジネス基盤センター 企画部
TEL: 044-739-1566(内線:3612)  FAX: 044-739-1548



From iakio ＠ pjam.jpweb.net  Fri May  2 13:00:37 2003
From: iakio ＠ pjam.jpweb.net (ISHIDA Akio)
Date: Fri, 2 May 2003 13:00:37 +0900
Subject: [pgsql-jp: 29783] Re: substring を使用した場合の検索結果について
In-Reply-To: <OF478637E2.9E00C2FF-ON49256D1A.00037EDA@citizen.co.jp>
References: <OF478637E2.9E00C2FF-ON49256D1A.00037EDA@citizen.co.jp>
Message-ID: <20030502130037.FA2FCA80.iakio@pjam.jpweb.net>

こんにちは。石田@苫小牧市です。

"Hirokazu Matsumura" <matsumurah ＠ citizen.co.jp> wrote:
(2003/05/02 10:05)

> 皆様おはようございます。松村です。
> 仲村様、油井様返答有難う御座いました（＾＾）
> 
> > この場合は取り敢えず, 関数インデックスを使わなければならないと思いま
> す.
> > http://developer.postgresql.org/docs/postgres/indexes-functional.html
> >
> > コストの見積もりが,
> > cost=0.00..1191.36 rows=108 width=238
> > に対して, 実際の結果が
> > actual time=175.69..345.42 rows=1 loops=1
> > となっていますが, 統計情報の更新(analyze)は行ないましたか?
> > #SET STATISTICS xxして, より詳細な統計と取ったりもできます..
> >
> > 確か結構前のバージョンからか, vacuumとanalyzeは別になったとか聞いたよ
> うな
> > あと, vacuumも単にvacuumでなくて, _一度_, vacuum full(排他的ロックが
> かか
> > ります)すると
> > 物理的に縮小される(ケースもある)ので, 微妙に早くなるかも知れません.
> 
> 関数インデックスを以下のようにして作成してみました。
> １．create index col2_substr on test1 (substring(cols,1,3))
> parse errorで怒られてしまいました（＾＾；

上記の URL にも書いてありますが、和訳では、
http://www.postgresql.jp/document/pg721doc/user/indexes-functional.
html
インデックス定義の関数は1つ以上の引数を取ることができますが、
定数ではなくテーブル列でなくてはいけません。

なので、例えば、

create function substr_1_3(text) returns text as 
'select substr($1, 1, 3)' language 'sql' with (iscachable, isstrict);

のような関数を定義して、

create index col2_substr on test1 (substr_1_3(cols))

としてやればうまくいくのではないでしょうか？

--
ISHIDA Akio<iakio ＠ pjam.jpweb.net>



From kino ＠ deneb.jp  Fri May  2 14:06:15 2003
From: kino ＠ deneb.jp (kinosita)
Date: Fri, 2 May 2003 14:06:15 +0900
Subject: [pgsql-jp: 29784] Re: vacuumdb のオプション(--analzye, --full) の運用時の使い方
References: <004c01c30d5a$155474a0$7b00a8c0@crew.findnet.jp> <20030501113352.DFAE.HOTTA@net-newbie.com> <20030501184744.A448D280.iakio@pjam.jpweb.net>
Message-ID: <012c01c31068$8edc95d0$7b00a8c0@crew.findnet.jp>

こんにちは。木下というものです。

堀田さん、石田さん、レスありがとうございます。

> > 識者ではないので質問には答えられませんが、一般的には、どの方法が
> > 一番速い（早い）かという問題は、データベースの使い方や環境に左右
> > される面が大きいと思われるので、まず「やってみる」ことが先決では
> > ないでしょうか。
> >
> > そして、何か自分の予想と異なった結果が出たら、そのことについて質
> > 問してみるとよいかと思います。ただし、その際も出せる限りの情報を
> > 出さないと、フォローがつくのはやはり難しいかもしれません。
> vaccum 自体が速く終了することも大切かもしれませんが、
> vaccum が適切なタイミングで行なわれることも重要です。
> そのタイミングも、データベースにどのようなデータが
> 格納されるかに左右されるので、やはり「やってみる」ことでしか
> 良い解はえられないでしょう。
> 一般的には、--analyze も --full もつけない vacuum を
> 頻繁に行ない、--analyze や --full はたまに行なうようです。

　どちらかというと、セオリーのようなものがあれば、教えていただこうと
　思ったのですが、やはり経験と勘になってしまうのですね。

　以前の経験では、１日１回のvacuum 実行では、次第に遅くなってしまい、
　４時間に１度のvacuum + １日１回の full オプション実行で、対応しました。
  ( DBの更新が頻繁な環境で、full オプションで処理時間が倍増した覚えがありま
す）
　　他の方々は、どうやっているのか？興味があって投稿させてもらいました。

> contrib/pgstattuple を定期的に実行して、
> tuple_percent が極端に減ってしまわないタイミングで vacuum
> を行なうのが良いでしょう。
> 以前は 1 時間に 1 度 vacuum するという例もありました。
> 場合によってやもっとやっても良いと思います。

　早速試してみます。
　レス、ありがとうございました。



From zensyo ＠ ann.tama.kawasaki.jp  Fri May  2 15:58:54 2003
From: zensyo ＠ ann.tama.kawasaki.jp (zensyo ＠ ann.tama.kawasaki.jp)
Date: Fri, 02 May 2003 15:58:54 +0900 (JST)
Subject: [pgsql-jp: 29785] リソースの制限
Message-ID: <20030502.155854.112536029.zensyo@ann.tama.kawasaki.jp>

鈴木と申します。

postgresql7.xを使用しているのですが複数ユーザで共用しており、ユーザご
とにアクセス数等のリソースを制限できないかと思っておりました。
（しばしば、特定ユーザのページへのアクセスが多くなることがあり困ってい
ました）

最近mysqlをさわる機会があり、実際に試したわけではないのですがマニュア
ルに

4.3.6 Limiting user resources
Starting from MySQL 4.0.2 one can limit certain resources per user.
So far, the only available method of limiting usage of MySQL server
resources has been setting the max_user_connections startup variable
to a non-zero value. But this method is strictly global and does not
allow for management of individual users, which could be of particular
interest to Internet Service Providers.
Therefore, management of three resources is introduced on the
individual user level:

    * Number of all queries per hour: All commands that could be run
      by a user.
    * Number of all updates per hour: Any command that changes any
      table or database.
    * Number of connections made per hour: New connections opened per
      hour. 

のようなリソース制限機能があることがわかりました。
postgresqlの場合、MLやwebを検索してみましたが、なかなかそれらしいもの
が見つかりませんでした。

すでにpostgresqlでのデータやPHPスクリプトがあるためできればpostgresql
のままでいきたいのですが、何か良い方法はないでしょうか。

# PAMで認証するようにして、PAMモジュールを改造しようかとも思ったのです
  が、PAMでのパスワード認証自体まだうまくいっていなかったりします。



From pgsql ＠ e-linez.com  Fri May  2 16:15:55 2003
From: pgsql ＠ e-linez.com (Masato Tanaka)
Date: Fri, 2 May 2003 16:15:55 +0900
Subject: [pgsql-jp: 29786] Re: Unable to convert date to tm
References: <007801c3104a$b3f1f9f0$4dedd8ca@e1> <001301c31052$da20a100$4dedd8ca@e1> <200305021214.04062.yu-kishimoto@saturin.co.jp>
Message-ID: <000701c3107a$ac72e010$4dedd8ca@e1>

田中です。

Kishimotoさん。ピンポイントのアドバイスありがとうございます。

おかげさまで解決いたしました。

この際なので最新のpostgresql-7.3.2にアップグレードしようと思っています。


----- Original Message ----- 
From: "Kishimoto Yuu" <yu-kishimoto ＠ saturin.co.jp>
To: <pgsql-jp ＠ ml.postgresql.jp>
Sent: Friday, May 02, 2003 12:14 PM
Subject: [pgsql-jp: 29781] Re: Unable to convert date to tm


> こんにちは、Kishimoto と申します。
>
> 金曜日 02 5月 2003 11:30、Masato Tanaka さんは書きました:
>
> > 書き忘れておりました。
> > OSはRedhat Linux7.3です。
> >
> > > こんにちは。田中と申します。
> > >
> > > Postgres7.2.1で困っています。
> > >
> > > 日付型のフィールドに、特定の日付が入っていると、TIMESTAMPで値を取得で
き
> >
> > ず、
> >
> > >  ERROR:  Unable to convert date to tm
> > > というメッセージが出てしまいます。
>
> http://www.jp.redhat.com/support/errata/RHSA/RHSA-2003-001J.html より
>
> |This update also contains fixes for several other PostgreSQL bugs,
> |including handling of pre-1970 date values in newer versions of glibc,
> |possible server shutdown hangs, spinlock hangs on SMP PPC machines, and
> |pg_dump improperly dumping with the FULL JOIN USING clauses
>
> と、あります。glibc の最新バージョンにおける PostgreSQL のバグのようです。
> 上記 URL にあるアップデートパッケージを適用することで、解決できるのでは
> ないでしょうか?
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>  Kishimoto Yuu <yu-kishimoto ＠ saturin.co.jp>
>
>




From mae ＠ itc-net.co.jp  Fri May  2 17:17:53 2003
From: mae ＠ itc-net.co.jp (前　宏尚)
Date: Fri, 02 May 2003 17:17:53 +0900
Subject: [pgsql-jp: 29787] EXEやバッチの起動について
Message-ID: <200305020816.RAA12175@ns.itc-net.co.jp>

はじめまして。前と申します。

早速ですが、質問させて頂きたいと思います。
ＥＸＥやバッチを、PL/pgSQLの中で実行させる方法
（Unix上で動作させる為、できればshellを実行させる方法）
を探しているのですが、いろいろなサイト、ドキュメント等を見ても、
それらしきものが載っておらず（読解力がないだけかもしれませんが）、
ご存知の方がおられましたら、どうかお知恵をお貸しいただけないでしょうか？
よろしくお願いいたします。


⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔
前　<mae ＠ itc-net.co.jp>
⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔




From yutaka ＠ hi-net.zaq.ne.jp  Fri May  2 17:52:16 2003
From: yutaka ＠ hi-net.zaq.ne.jp (Yutaka tanida)
Date: Fri, 02 May 2003 17:52:16 +0900
Subject: [pgsql-jp: 29788] Re: EXEやバッチの起動について
In-Reply-To: <200305020816.RAA12175@ns.itc-net.co.jp>
References: <200305020816.RAA12175@ns.itc-net.co.jp>
Message-ID: <20030502172929.E570.YUTAKA@hi-net.zaq.ne.jp>

谷田です。

On Fri, 02 May 2003 17:17:53 +0900
前　宏尚 <mae ＠ itc-net.co.jp> wrote:

> 早速ですが、質問させて頂きたいと思います。
> ＥＸＥやバッチを、PL/pgSQLの中で実行させる方法
> （Unix上で動作させる為、できればshellを実行させる方法）
> を探しているのですが、いろいろなサイト、ドキュメント等を見ても、
> それらしきものが載っておらず（読解力がないだけかもしれませんが）、
> ご存知の方がおられましたら、どうかお知恵をお貸しいただけないでしょうか？
> よろしくお願いいたします。

ストアドプロシージャから外部プロセスを呼ぶというのは、OSデバイスドライバ
から外部プロセスを呼ぶぐらい恐ろしいことだと思うのですが・・・ま、
PostgreSQLの現在の実装なら大丈夫じゃないかと思いますが。

・自分でC関数を作る
・PL/Perlとかを使う

といった方法はあると思います。

# そういえばIllustraからIUSになったときに、この辺の関数が
# 移植されなかったなぁ

-- 
Yutaka tanida <yutaka ＠ nonsensecorner.com>
http://www.nonsensecorner.com/



From snaga ＠ snaga.org  Fri May  2 22:31:26 2003
From: snaga ＠ snaga.org (Satoshi Nagayasu)
Date: Fri, 2 May 2003 22:31:26 +0900
Subject: [pgsql-jp: 29789] PostgreSQL Conference 2003 申し込み開始のお知らせ
Message-ID: <20030502223126.14cc3ad9.snaga@snaga.org>

pgsql-jpの皆様、

永安＠JPUG です。

日本PostgreSQLユーザー会では、下記の要領でカンファレンスを行います。
ユーザー会の総会も併催となっております。

今回は、特に大規模なWebシステムの構築、およびパフォーマンスチューニング
に焦点を当てた企画となっております。普段はあまり聞かれない内容も出るかと
思いますので、ぜひこの機会にご参加ください。

よろしくお願いいたします。

-----------------------------------------------------------------------

                PostgreSQL Conference 2003 開催のお知らせ
               ===========================================

このたび、日本PostgreSQLユーザー会は第5回会員総会にあわせてPostgreSQL
Conference 2003 を開催いたします。今年の Conferene は大規模データベー
スをテーマに2トラック計8セッションにて行います。是非、ご参加下さい。

セミナー情報URL(随時更新の可能性あり): 
      http://www.postgresql.jp/misc/seminar/

【開催概要】

	主催   日本PostgreSQLユーザー会 
	日時  2003年5月17日(土)
               10:00-15:20  PostgreSQL Conference 2003
               15:30-16:45  JPUG会員総会
               17:00-19:00  懇親会 
        参加費 正会員   1,000円
               一般     3,000円
               協賛会員 口数分まで無料
	会場  ダイアモンドホテル
	        東京都千代田区一番町25番地
	        TEL　03-3263-9191　FAX　03-3263-2222
	        営団地下鉄半蔵門線半蔵門駅　No.4出口直結
		http://www.diamond-hotel.co.jp/map.html
               * Conference,総会,懇親会共に同会場となります
     参加方法 事前申し込みが必須です。下記からお申し込み下さい。
              http://www.postgresql.jp/~snaga/regist/regist.php3


【プログラム】

9:30-  受付開始 

10:00-10:10 ご挨拶 

10:10-11:00 
	A-1　荒谷 浩二 氏（日本PostgreSQLユーザー会理事）
　　　　「高可用性データベースシステム実現の為のクラスタリングシステムの導入」
	B-1　杉田 研治 氏（株式会社 SRA）
　　　　「PostgreSQL チューニング入門」  

11:00-11:10 休憩 

11:10-12:00 
	A-2　渡部 広志 氏（株式会社 NTT データ）
　　　　「大規模会員管理システムへの PostgreSQL の適用事例」
	B-2　島田 洋一 氏（ストアゲート）
　　　　「実用的 PostgreSQL ベンチマークツール開発「OSDL/DBT プロジェクト」について」  

12:00-13:30 お昼休憩 

13:30-14:20 
	A-3　大垣 靖男 氏（日本 PHP ユーザー会）
　　　　「PostgreSQLとPHPを使った大規模Webサイトの構築」
	B-3　永安 悟史 氏（日本PostgreSQLユーザー会理事）
　　　　  「PostgreSQLにおける二相コミットとその応用」

14:20-14:30 休憩 

14:30-15:20 
	A-4　片岡 裕生 氏（日本PostgreSQLユーザー会理事）
　　　　「アーキテクチャ解説〜ストレージ入出力」
	B-4　三谷 篤 氏（JPUG 広島）
　　　　「レプリケーションシステム、PGReplicate の現状と最新動向」  

15:30-16:45
	会員総会

17:00-19:00
	懇親会(ダイヤモンドホテル内で立食パーティ)

----------------------------------------------------------------------
  日本PostgreSQLユーザー会(JPUG: Japan PostgreSQL User Group) 事務局
              URI:    http://www.postgresql.jp
              Mail:   jpug-staff ＠ postgresql.jp
----------------------------------------------------------------------

-- 
NAGAYASU Satoshi <snaga ＠ snaga.org>


From ono ＠ fjct.fujitsu.com  Mon May  5 10:23:59 2003
From: ono ＠ fjct.fujitsu.com (Kenji ono)
Date: Mon, 5 May 2003 10:23:59 +0900
Subject: [pgsql-jp: 29790] SQLの文字列長制限について
Message-ID: <200305051023.HEI11946.OPP@fjct.fujitsu.com>

皆さんこんにちは、小野と言います。

環境は、Redhat7.3+PostgreSQL7.3.2です。
PC環境はCPU=P4 2G+MEM=512です。
これに、JDK1.4+JDBC1.2で接続するWEBアプリケーションを開発して
います。

最近顧客から１テーブルで1,000項目ぐらい管理できるか、と問われた
ので、PostgreSQLでは1,600項目管理できます、と答えております。
答えながらJDBCでSQLを送信できる制限長が32Kとどこかに書いてあった
のを思いだしました。
そこで、SELECT 列名,・・・ From hoge を37Kまでかいてみたのですが
エラーになりませんでした。

そこで、String型の定義はSunが提供するAPIを調べてみたのですが、
内部的に長さをInt型で保存しており、Int型にはMAX_VALUEとして
定数値 2,147,483,647Byteが定義されてました。
だとすると、Javaの理論上はString型にinteger.MAX_VALUE値までの
長さの文字列が格納でき、そのままexecuteUpdateなどができるので
しょうか。

Javaねたかもしれないのですが、JavaHouseでも発言がなかったので
こちらに投稿しました。

宜しくお願い申し上げます。

--
富士通キャドテック（株）コーポレートシス事）ＩＢＳ
小野　健二（Kenji ono）
電話：内7195-3824 / 外045-470-1085
メール：ono ＠ fjct.fujitsu.com


From tanaka.hideki ＠ future.co.jp  Tue May  6 07:58:32 2003
From: tanaka.hideki ＠ future.co.jp (tanaka.hideki ＠ future.co.jp)
Date: Tue, 6 May 2003 07:58:32 +0900
Subject: [pgsql-jp: 29791] 親キー削除時（DELETE CASCADEあり）の子テーブルのトリガーの動作について
Message-ID: <D76C00438333264F8D4B4409D9EF2F15E7C721@003POST.future.co.jp>

> お世話になっております。PostgreSQLのトリガーの基本動作についてご質問が
> あります。
> 
> 動作環境
> OS:RedHat  
> PostgreSQL:7.2
> 
> 親子関係のあるテーブルにおいて子テーブルに定義したトリガーについての質問を
> させていただきたいと思います。
> 子テーブルにレコード削除時（BEFORE/AFTERどちらでもよい）にトリガーを動作
> させたいと思っています。親テーブルのレコード削除時（DELETE CASCADE)に
> 子テーブルのレコードも削除されると思いますが、この場合、子テーブルのトリガーは
> 動作するのでしょうか？
> 
> 以上
> 
> 
> 


From matsumurah ＠ citizen.co.jp  Tue May  6 17:19:30 2003
From: matsumurah ＠ citizen.co.jp (Hirokazu Matsumura)
Date: Tue, 6 May 2003 17:19:30 +0900
Subject: [pgsql-jp: 29792] Re: substring を使用した場合の検索結果について
Message-ID: <OF0115FA7C.8CA17A68-ON49256D1E.00295D44@citizen.co.jp>

石田様、返信が遅くなって申し訳御座いません。
松村です。

> 上記の URL にも書いてありますが、和訳では、
> http://www.postgresql.jp/document/pg721doc/user/indexes-functional.
> html
> インデックス定義の関数は1つ以上の引数を取ることができますが、
> 定数ではなくテーブル列でなくてはいけません。
>
> なので、例えば、
>
> create function substr_1_3(text) returns text as
> 'select substr($1, 1, 3)' language 'sql' with (iscachable, isstrict);
>
> のような関数を定義して、
>
> create index col2_substr on test1 (substr_1_3(cols))
>
> としてやればうまくいくのではないでしょうか？

なるほど。和訳のページは既に拝見していたのですが、全然理解できませんで
した。すいません。
丁寧に例題まで出して頂き、又解りやすく説明して頂きまして大変有難うござ
います。

今さっき、「f_substr10」という関数をcreate functionして関数Indexを作成
して
試してみました。（名称等は適当です）
******************************************************************
substrにて
******************************************************************
explain analyze select * from test01 where substr(col1,1,10)
= '1234567890';

------------------------------------------------------------------
 Seq Scan on test01  (cost=0.00..9186.84 rows=108 width=249)
 (actual time=8745.45..8745.45 rows=0 loops=1)
   Filter: (substr((col1)::text, 1, 10) = '1234567890'::text)

 Total runtime: 8745.74 msec
(3 rows)

******************************************************************
f_substr10にて
******************************************************************
explain analyze select * from test01 where f_substr10(col1)
= '1234567890';

-------------------------------------------------------------------
 Index Scan using test01_idx01 on test01  (cost=0.00..434.22 rows=108
width=249)
 (actual time=0.61..0.61 rows=0 loops=1)
   Index Cond: (f_substr10((col1)::text) = '1234567890'::text)

 Total runtime: 0.91 msec
(3 rows)
******************************************************************

おお〜！石田様のおっしゃる通りIndexも使用されたみたいでとても速くなりま
した！（＾＾）

今回は１０桁の項目を作り、そこに対してIndexを貼るというヘンな力技の対応
をしてしまいましたが、
今後の糧とさせて頂きます。
（暇があればこの様に修正したいのですが．．．）

どうも有難う御座いました！！

----------------------------------------------
松村 浩一
----------------------------------------------



From kmatsuda ＠ lisonal.com  Tue May  6 18:32:02 2003
From: kmatsuda ＠ lisonal.com (松田勝己)
Date: Tue, 06 May 2003 18:32:02 +0900
Subject: [pgsql-jp: 29793] JpgManを紹介させてください
Message-ID: <200305060932.AA00687@kmatsuda.lisonal.com>

こんにちわ、松田＠リソナルです
このMLに投稿するのは、3年振りぐらいです。

以前、私はpgManというPHPで作ったPostgreSQL管理ツールを
アナウンスさせて頂きました。
今回、Javaクライアントとして動作するJpgManの開発を始めました。
詳細URLはこちらです。
http://www.lisonal.com/index.php?JpgMan

ずっと放置状態だったpgManのページはJpgMan公開を機に
閉鎖しました、理由は上記URLに書いてあります。

以下にJpgManの特徴を公開ページより抜粋します。

JpgManはpgManと何が違うの？ 
　JpgManはブラウザから離れ、SWINGを使ったJavaアプリケーションです。
　ブラウザでは不可能なユーザーインターフェースと使い勝手を実現
　しようとしています。 

もう少し具体的にJpgManについて教えて 
　JpgManはマルチデーターベースマネジメントツールを目指しています。
　また、オブジェクト指向言語としてのJavaを活かした設計になっています。 

　１、XML設定ファイルに設定を追加・変更するだけで、複数の異なる種類の
　データベースを管理出来るような設計になっています。
　いずれはGUIによる設定追加・変更が出来るようにする予定です。 

　２、容易に機能の追加が出来るように、プラグインの機能を持っています。
　JpgManではデータベースがよく利用される業務アプリケーションの機能を
　追加することを想定しています。 

　３、マルチスレッドを使った設計になっているので、処理に時間のかかるSQL文を
　実行中でも画面がロックされることはありません、また複数のデータベース処理を
　並行して実行することが出来ます。 

まだ開発が始まったばかりですが、多くの方に使って頂けるよう
育てて行こうと思いますので、ご興味がありましたら使ってみてください。

------------------------------
有限会社リソナル 松田 勝己
E-Mail:kmatsuda ＠ lisonal.com URL:http://www.lisonal.com/
TEL   :03-3643-4991 FAX:03-3643-4993
得盛サーバーハウジング
http://www.lisonal.com/index.php?%5B%5B%C6%C0%C0%B9%5D%5D


From mae ＠ itc-net.co.jp  Wed May  7 09:55:35 2003
From: mae ＠ itc-net.co.jp (前　宏尚)
Date: Wed, 07 May 2003 09:55:35 +0900
Subject: [pgsql-jp: 29794] Re: EXEやバッチの起動について
In-Reply-To: <20030502172929.E570.YUTAKA@hi-net.zaq.ne.jp>
References: <20030502172929.E570.YUTAKA@hi-net.zaq.ne.jp>
Message-ID: <200305070053.JAA23930@ns.itc-net.co.jp>

谷田様。

> ストアドプロシージャから外部プロセスを呼ぶというのは、OSデバイスドライバ
> から外部プロセスを呼ぶぐらい恐ろしいことだと思うのですが・・・ま、
> PostgreSQLの現在の実装なら大丈夫じゃないかと思いますが。
> 
> ・自分でC関数を作る
> ・PL/Perlとかを使う
> 
> といった方法はあると思います。
> 
> # そういえばIllustraからIUSになったときに、この辺の関数が
> # 移植されなかったなぁ

ご回答、ありがとうございます。
参考にさせていただきたいと思います。

⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔
前　<mae ＠ itc-net.co.jp>
⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔



From sorako_y ＠ hotmail.com  Wed May  7 16:53:46 2003
From: sorako_y ＠ hotmail.com (sorako yamamoto)
Date: Wed, 07 May 2003 07:53:46 +0000
Subject: [pgsql-jp: 29795] int型の分をhh:ii形式に直す方法
Message-ID: <Law15-F73vzyJxArGvn000020e8@hotmail.com>

こんにちは。いつも勉強させていただいております。

postgreSQLでカラムに"分のint型データ"を持っているのですが、
selectするときに、
200分 → 3：20
のようにして取ってきたいですが、今一歩のところでつまずいています。


200/60 . "：" . "mod(200, 60)" の形式で取ってくるにはどうしたらよいでしょう
か。


ほんとにほんとに基礎的な質問で恐縮なのですが…
ご助言いただけないでしょうか。よろしくお願いします。


やまもと　そらこ。

_________________________________________________________________
自宅の PC で英語力をアップ MSN 英会話   http://englishtown.msn.co.jp/  



From sugita ＠ sra.co.jp  Wed May  7 17:05:52 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Wed, 07 May 2003 17:05:52 +0900 (JST)
Subject: [pgsql-jp: 29796] Re: int型の分をhh:ii 形式に直す方法
In-Reply-To: <Law15-F73vzyJxArGvn000020e8@hotmail.com>
References: <Law15-F73vzyJxArGvn000020e8@hotmail.com>
Message-ID: <20030507.170552.28795987.sugita@sra.co.jp>

  杉田です。

From: "sorako yamamoto" <sorako_y ＠ hotmail.com>
Subject: [pgsql-jp: 29795] int型の分をhh:ii 形式に直す方法
Date: Wed, 07 May 2003 07:53:46 +0000

;;; postgreSQLでカラムに"分のint型データ"を持っているのですが、
;;; selectするときに、
;;; 200分 → 3：20
;;; のようにして取ってきたいですが、今一歩のところでつまずいています。
;;; 
;;; 
;;; 200/60 . "：" . "mod(200, 60)" の形式で取ってくるにはどうしたらよいでしょう
;;; か。

  このようなのでよいでしょうか?

    => select (n / 60 || ':' || n % 60) as hour from (select 200 as n) as m;
     hour
    ------
     3:20
    (1 row)

    => 


Kenji Sugita                                      



From mashiki ＠ yanah.com  Wed May  7 20:09:56 2003
From: mashiki ＠ yanah.com (Mashiki)
Date: Wed, 07 May 2003 20:09:56 +0900
Subject: [pgsql-jp: 29797] Re: int型の分をhh:ii  形式に直す方法
In-Reply-To: <20030507.170552.28795987.sugita@sra.co.jp>
References: <20030507.170552.28795987.sugita@sra.co.jp>
Message-ID: <11C31489310598mashiki@yanah.com>

　Mashikiです。

>    => select (n / 60 || ':' || n % 60) as hour from (select 200 as n) as m;
>     hour
>    ------
>     3:20
>    (1 row)

別解ですが、

select (n || ' min')::interval from (select 200 as n) as m;

な方法を使うのもhourが24時間を越えたときに日数を切り出す処理も
行うつもりであれば、to_char 等で結果出力を行いやすいです。

7.3.2で確認。


From t.hayakawa ＠ digicom.dnp.co.jp  Thu May  8 10:22:40 2003
From: t.hayakawa ＠ digicom.dnp.co.jp (Tohru Hayakawa)
Date: Thu, 8 May 2003 10:22:40 +0900
Subject: [pgsql-jp: 29798] 再起的にデータ数をカウントするには？
Message-ID: <8F93121A-80F3-11D7-A775-0003938C6262@digicom.dnp.co.jp>

例えば...
┌───────┐
│部署　　　　　│
┝━━━━━━━┥
│部署＿ｃｄ　　│≪┐≪┐
│部署名　　　　│　│　│
│親部署＿ｃｄ　│＜┘　│
└───────┘　　　│
┌───────┐　　　│
│社員　　　　　│　　　│
┝━━━━━━━┥　　　│
│氏名　　　　　│　　　│
│所属部署＿ｃｄ│≪──┘
└───────┘
というテーブルがあったとして、
ある部署以下の「のべ社員数」を求めるにはどのようなSQL文を書けばよいのでしょうか。。



From aoki-kazuyuki ＠ nifty.com  Thu May  8 10:29:49 2003
From: aoki-kazuyuki ＠ nifty.com (aoki-kazuyuki ＠ nifty.com)
Date: Thu, 8 May 2003 10:29:49 +0900
Subject: [pgsql-jp: 29799] Re: 再起的にデータ数をカウントするには？
References: <8F93121A-80F3-11D7-A775-0003938C6262@digicom.dnp.co.jp>
Message-ID: <074e01c31501$5140fcf0$0200a8c0@AOKIVAIO>

これでいかがでしょうか？

SELECT count(*) FROM 社員 WHERE 所属部署＿ｃｄ IN
 (SELECT 所属部署＿ｃｄ FROM 部署 WHERE 親部署＿ｃｄ= 'hogehoe' )



> 例えば...
> ┌───────┐
> │部署　　　　　│
> ┝━━━━━━━┥
> │部署＿ｃｄ　　│≪┐≪┐
> │部署名　　　　│　│　│
> │親部署＿ｃｄ　│＜┘　│
> └───────┘　　　│
> ┌───────┐　　　│
> │社員　　　　　│　　　│
> ┝━━━━━━━┥　　　│
> │氏名　　　　　│　　　│
> │所属部署＿ｃｄ│≪──┘
> └───────┘
> というテーブルがあったとして、
> ある部署以下の「のべ社員数」を求めるにはどのようなSQL文を書けばよいので
しょうか。。
>
>




From sorako_y ＠ hotmail.com  Thu May  8 11:13:15 2003
From: sorako_y ＠ hotmail.com (sorako yamamoto)
Date: Thu, 08 May 2003 02:13:15 +0000
Subject: [pgsql-jp: 29800] Re: int型の分をhh:ii 形式に直す方法
Message-ID: <Law15-F94P4MZ7tcQuj00006057@hotmail.com>

杉田さん、Mashikiさんどうもありがとうございます。
（MashikiさんはPHPメーリングリストともどもお世話になっております)

おかげ様で無事、データを取得することができました。

Mashikiさんのご回答で思ったのですが、postgresには、inteｒval型があるんですね
…
わざわざカラムを分のint型データにせずにintervalにすればよかったです。
休憩時間用のカラムで、時間を分単位で持ちたかったんです。
普通こういう時はinterval型を使うものですか？

あと、みなさんSQLはどのように勉強されているのでしょうか。
リファレンス本やサイト等参考にされていますか？

重ね重ね恐縮ですが、アドバイスいただけたらうれしいです。

やまもと　そらこ。

_________________________________________________________________
最新のファイナンス情報とライフプランのアドバイス MSN マネー  
http://money.msn.co.jp/  



From ishikawa-t ＠ comtecc.net  Thu May  8 11:31:35 2003
From: ishikawa-t ＠ comtecc.net (Tatsuro Ishikawa)
Date: Thu, 08 May 2003 11:31:35 +0900
Subject: [pgsql-jp: 29801] SMP及びCPUの効果
Message-ID: <20030508112228.FCC8.ISHIKAWA-T@comtecc.net>

石川と申します。

現在
　　ReadHat linux 8.0
　　PostgreSQL 7.3.2
　　メモリー　２G
の構成を予定しているシステムを設計していますが、動作ハードの選定で質問さ
せてください。

１．CPUは、Pentinum IIIとXeonでどの程度パフォーマンスの違いが出るのでしょ
　　うか？

２．CPU１個と２個では、どの程度パフォーマンスの違いが出るのでしょうか？

３．CPUの個数よりもメモリーの追加（３G又は４G）の方がパフォーマンス向上
　　の効果があるのでしょうか？

上記　３点を基にハードの選定を行いたいと考えています。

すいませんが、ご教授お願いします


From t.hayakawa ＠ digicom.dnp.co.jp  Thu May  8 11:40:42 2003
From: t.hayakawa ＠ digicom.dnp.co.jp (Tohru Hayakawa)
Date: Thu, 8 May 2003 11:40:42 +0900
Subject: [pgsql-jp: 29802] Re: 再起的にデータ数をカウントするには
In-Reply-To: <074e01c31501$5140fcf0$0200a8c0@AOKIVAIO>
Message-ID: <7622F596-80FE-11D7-A775-0003938C6262@digicom.dnp.co.jp>

> SELECT count(*) FROM 社員 WHERE 所属部署＿ｃｄ IN
>  (SELECT 所属部署＿ｃｄ FROM 部署 WHERE 親部署＿ｃｄ= 'hogehoe' )

これで試してみたのですが、どうしてもカウントがゼロになってしまいます。

私が考えるには再起部分は

　select *
　from 部署 子エイリアス,部署 親エイリアス
　where 子エイリアス.親部署＿ｃｄ=親エイリアス.部署＿ｃｄ

といった具合で書けるように思うのですが、
疑問は
　「もっとも親の部署のコードをどうやって指定するのか」
といった点にあります。

よろしくお願いします。

>> 例えば...
>> ┌───────┐
>> │部署　　　　　│
>> ┝━━━━━━━┥
>> │部署＿ｃｄ　　│≪┐≪┐
>> │部署名　　　　│　│　│
>> │親部署＿ｃｄ　│＜┘　│
>> └───────┘　　　│
>> ┌───────┐　　　│
>> │社員　　　　　│　　　│
>> ┝━━━━━━━┥　　　│
>> │氏名　　　　　│　　　│
>> │所属部署＿ｃｄ│≪──┘
>> └───────┘
>> というテーブルがあったとして、
>> ある部署以下の「のべ社員数」を求めるには
>> どのようなSQL文を書けばよいのでしょうか。。



From uramoto ＠ katch.ne.jp  Thu May  8 11:53:33 2003
From: uramoto ＠ katch.ne.jp (Seiji Uramoto)
Date: Thu, 08 May 2003 11:53:33 +0900
Subject: [pgsql-jp: 29803] Re: int型の分をhh:ii  形式に直す方法
References: <Law15-F94P4MZ7tcQuj00006057@hotmail.com>
Message-ID: <3EB9C6AD.30602@katch.ne.jp>

浦本といいます。

sorako yamamoto wrote:
> Mashikiさんのご回答で思ったのですが、postgresには、inteｒval型があるんですね
> …
> わざわざカラムを分のint型データにせずにintervalにすればよかったです。
> 休憩時間用のカラムで、時間を分単位で持ちたかったんです。
> 普通こういう時はinterval型を使うものですか？

interval 型は、SQL99 から導入されたデータ型です。
そのため、まだ実装されていない RDBMS もあるでしょう。

他の RDBMS に移植することを考えると、ちょっと考えてしまいますが、
どの RDBMS も近いうちに実装してくると思いますので、
今回のような場合なら、 interval 型を採用するのは
ベストだと思います。

> あと、みなさんSQLはどのように勉強されているのでしょうか。
> リファレンス本やサイト等参考にされていますか？

えぇと、
1) PostgreSQL を使っている。
2) SQL を勉強したい。
となると、コレしかないでしょう。

「SQL クリックリファレンス」
http://www.oreilly.co.jp/BOOK/sql/
発行 : オライリー・ジャパン
ISBN : 4-87311-055-6

3) PHP と組み合わせで勉強したい。
というのならば、別のチョイスも。

でわ。



From t-ishii ＠ sra.co.jp  Thu May  8 12:09:50 2003
From: t-ishii ＠ sra.co.jp (Tatsuo Ishii)
Date: Thu, 08 May 2003 12:09:50 +0900 (JST)
Subject: [pgsql-jp: 29804] Re: int型の分をhh:ii 形式に直す方法
In-Reply-To: <3EB9C6AD.30602@katch.ne.jp>
References: <Law15-F94P4MZ7tcQuj00006057@hotmail.com>
	<3EB9C6AD.30602@katch.ne.jp>
Message-ID: <20030508.120950.104030594.t-ishii@sra.co.jp>

石井です．

> 浦本といいます。
> 
> sorako yamamoto wrote:
> > Mashikiさんのご回答で思ったのですが、postgresには、inteｒval型があるんですね
> > …
> > わざわざカラムを分のint型データにせずにintervalにすればよかったです。
> > 休憩時間用のカラムで、時間を分単位で持ちたかったんです。
> > 普通こういう時はinterval型を使うものですか？
> 
> interval 型は、SQL99 から導入されたデータ型です。
> そのため、まだ実装されていない RDBMS もあるでしょう。

interval 型は SQL92 ですでに定義されていますよ．つまり10年以上前からあ
るわけです．いまだにサポートしていない RDBS があるとしたら，それはちょっ
と怠慢なのでは:-)
--
Tatsuo Ishii


From sakanaka ＠ tokyo-gas.co.jp  Thu May  8 12:26:11 2003
From: sakanaka ＠ tokyo-gas.co.jp (SAKANAKA Tatsumi)
Date: Thu, 08 May 2003 12:26:11 +0900
Subject: [pgsql-jp: 29805] Re: 再起的にデータ数をカウントするには
In-Reply-To: <7622F596-80FE-11D7-A775-0003938C6262@digicom.dnp.co.jp>
References: <074e01c31501$5140fcf0$0200a8c0@AOKIVAIO>
	<7622F596-80FE-11D7-A775-0003938C6262@digicom.dnp.co.jp>
Message-ID: <75llxit8z0.wl%sakanaka@tokyo-gas.co.jp>

ツリーになってるんですよね？

ぼくは SQL だけで書くのはできなくてあきらめました。

結局、PL/pgSQL で、ある部署が、ある部署の先祖かどうかを判定する
関数 is_ancestor(部署, 先祖部署) とか？ を書いて

SELECT count(社員.氏名) FROM 社員
  JOIN 部署 ON 社員.所属部署＿ｃｄ =  部署.部署＿ｃｄ
  WHERE is_ancestor(部署.部署＿ｃｄ, '先祖') = true;

なんてことをしたような記憶があります（と思ってソースを探したら、
微妙に違うものをツリーのループ検出用トリガに使ってました）。

is_ancestor は部署.部署＿ｃｄ から、「上の方」に（再帰呼び出しで
はなく、単純に LOOP で）手繰っていって、どこかで部署.部署＿ｃｄ
が "hoge" にマッチすれば「先祖」ですから、true を返します。

最上位部署の "親部署_cd" が NULL でもいいなら、「上の方」に手繰っ
ていくとき、毎回 IF "親部署_cd" IS NULL してみて、NULL なら false
を返すようにすればよいと思います。

# SELECT INTO で、テーブル決めうちになるので、汎用性はまるであり
# ませんし、部署の数が多くなってくると実用に耐えるかどうか。また、
# SET を返す関数を作って、再帰呼び出しで全子孫を返すようにもでき
# ますね（これだと IN SELECT が使える）。

--さかなか＠関数 index とか使えるのだろうか？ 勉強不足。


From fkit.s ＠ sys238.jp  Thu May  8 12:47:42 2003
From: fkit.s ＠ sys238.jp (fumiyaKitamura)
Date: Thu, 8 May 2003 12:47:42 +0900
Subject: [pgsql-jp: 29806] Re: 再起的にデータ数をカウントするには
In-Reply-To: <7622F596-80FE-11D7-A775-0003938C6262@digicom.dnp.co.jp>
Message-ID: <D26769C4-8107-11D7-B7C1-000393C7A1A2@sys238.jp>

キタムラです。

select
　b.部署＿ｃｄ,count(*)
from
  部門 as b, 社員 as s
where
  b.部署＿ｃｄ = s.所属部署＿ｃｄ
group by
  b.部署＿ｃｄ

とか、

select
　b.親部署＿ｃｄ,count(*)
from
  部門 as b, 社員 as s
where
  b.部署＿ｃｄ = s.所属部署＿ｃｄ
group by
  b.親部署＿ｃｄ

と言うのではダメですか？



On 2003.5.8, at 11:40 Asia/Tokyo, Tohru Hayakawa wrote:

>> SELECT count(*) FROM 社員 WHERE 所属部署＿ｃｄ IN
>>  (SELECT 所属部署＿ｃｄ FROM 部署 WHERE 親部署＿ｃｄ= 'hogehoe' )
>
> これで試してみたのですが、どうしてもカウントがゼロになってしまいます。


>>> ┌───────┐
>>> │部署　　　　　│
>>> ┝━━━━━━━┥
>>> │部署＿ｃｄ　　│≪┐≪┐
>>> │部署名　　　　│　│　│
>>> │親部署＿ｃｄ　│＜┘　│
>>> └───────┘　　　│
>>> ┌───────┐　　　│
>>> │社員　　　　　│　　　│
>>> ┝━━━━━━━┥　　　│
>>> │氏名　　　　　│　　　│
>>> │所属部署＿ｃｄ│≪──┘
>>> └───────┘

=================<F.Kitamura>=================
E-Mail  : fkit ＠ sys238.jp
---
The greatest enemy of man is alcohol.
But, The Bible tells us to love our enemy.
==============================================



From tadano ＠ d-product.co.jp  Thu May  8 12:54:48 2003
From: tadano ＠ d-product.co.jp (Masayuki Tadano)
Date: Thu, 08 May 2003 12:54:48 +0900
Subject: [pgsql-jp: 29807] Re: 再起的にデータ数をカウントするには
In-Reply-To: <7622F596-80FE-11D7-A775-0003938C6262@digicom.dnp.co.jp>
References: <074e01c31501$5140fcf0$0200a8c0@AOKIVAIO> <7622F596-80FE-11D7-A775-0003938C6262@digicom.dnp.co.jp>
Message-ID: <20030508125216.79C8.TADANO@d-product.co.jp>

ただのともうします。

Tohru Hayakawa <t.hayakawa ＠ digicom.dnp.co.jp> wrote:

> 疑問は
> 　「もっとも親の部署のコードをどうやって指定するのか」
> といった点にあります。

部署の関係がツリー(というか階層的)になっているのですよね。
もしかすると、

http://ml.postgresql.jp/pgsql-jp-old/pgsql-jp/2001Oct/msg00037.html
や
http://ml.postgresql.jp/pipermail/pgsql-jp/2002-March/000301.html
のスレッドあたりが、参考になるかも。


-- 
Masayuki Tadano <tadano ＠ d-product.co.jp>




From chibacchi ＠ mb.infosnow.ne.jp  Thu May  8 13:00:42 2003
From: chibacchi ＠ mb.infosnow.ne.jp (Hisashi Chiba)
Date: Thu, 8 May 2003 13:00:42 +0900
Subject: [pgsql-jp: 29808] postmaster が再起動不能
Message-ID: <011001c31516$651b2f10$7d334a87@PHOBOS>

千葉と申します。

PostgreSQL 7.2 を利用しているのですが、作業をしている最中に、突然エラーが出
始めたので、
postmaster を停止させ、再起動しようとしたのですが、起動する事が出来なくなっ
てしまいました。

作業としては
$ psql -d db -c "copy table from '/home/postgres/data/datafile.euc'
delimiters ',';"
としていました。

このとき、データに整合性がとれない箇所が頻発したので、 vi で編集し、上記を数
回繰り返していた
のですが、突然、以下のエラーメッセージが出て、作業が出来なくなりました。

psql: FATAL 1:  XLogFlush: request A/C4CCA370 is not satisfied --- flushed
only to A/C40E3194

そこで、一度 postmaster を停止させ、再起動したのですが、
$ /etc/rc.d/init.d/postgres stop
Stopping postgres: postmaster [1955 1954 1953]
$ /etc/rc.d/init.d/postgres start
Starting postgres: postmaster []
と表示されて、念のため ps aux | grep postgres としても、やはりプロセスは存在
しませんでした。

再度、起動しようと
$ /etc/rc.d/init.d/postgres stop
Stopping postgres:
$ /etc/rc.d/init.d/postgres start
Starting postgres: postmaster []
としてて駄目でした。

どこを調べて、何をすれば起動出来るのか、皆目見当がつきません。
皆様の知識をお借りしたく、お待ちしております。



From a-atsumi ＠ technobank.co.jp  Thu May  8 13:05:42 2003
From: a-atsumi ＠ technobank.co.jp (Akira Atsumi)
Date: Thu, 8 May 2003 13:05:42 +0900
Subject: [pgsql-jp: 29809] Re: SMP 及びCPUの効果
In-Reply-To: <20030508112228.FCC8.ISHIKAWA-T@comtecc.net>
References: <20030508112228.FCC8.ISHIKAWA-T@comtecc.net>
Message-ID: <200305081305.IDC93759.BNT-JBVU@technobank.co.jp>

あつみです。

　DBサーバーの性能の要素はCPUだけではなく、CPU,メモリ,HDDが大きく
関係してきます。もちろんデータ量や用途にもよりますが、CPUだけ強く
しても必ずしもパフォーマンスが上がるとは言えません。
　その事を踏まえた上で、

> １．CPUは、Pentinum IIIとXeonでどの程度パフォーマンスの違いが出るのでしょ
> 　　うか？

　CPUの処理能力に限って言えば、単純にIntelの示したデータの通りに
なると思います。

> ２．CPU１個と２個では、どの程度パフォーマンスの違いが出るのでしょうか？

　これは誤解されていることが多いようなのですが、CPUが多いマシンは
決して速いわけではありません。処理が集中した時に重くならないだけ
です。（1つのSQLを複数のCPUに分散して処理するようなDBエンジンであ
れば別ですが）
　ですので、使い方によって、1CPUで充分な場合もあるでしょうし、4CPU
あった方がいい場合もあると思います。

> ３．CPUの個数よりもメモリーの追加（３G又は４G）の方がパフォーマンス向上
> 　　の効果があるのでしょうか？

　メモリについては私も良く分かりませんが、あんまり沢山積んでもうま
く使ってくれなかったような・・・。


　ですが、サーバーの選定という意味で言うなら、大は小を兼ねるです。
　もし私がどちらか迷ったら、大きい方を取ると思います。
　1CPUと2CPUがそんな極端に値段が違うわけでもありませんし、メモリ
もそんなに高くありません。予算がシビアでなければ、大きい方を取っ
て自分で経験してみるのが良いと思いますよ。
　（小さい方を取って経験してみるというのももちろんアリですが）

-----
Akira Atsumi
a-atsumi ＠ technobank.co.jp


From uramoto ＠ katch.ne.jp  Thu May  8 13:08:37 2003
From: uramoto ＠ katch.ne.jp (Seiji Uramoto)
Date: Thu, 08 May 2003 13:08:37 +0900
Subject: [pgsql-jp: 29810] Re: int型の分をhh:ii  形式に直す方法
References: <Law15-F94P4MZ7tcQuj00006057@hotmail.com>	<3EB9C6AD.30602@katch.ne.jp> <20030508.120950.104030594.t-ishii@sra.co.jp>
Message-ID: <3EB9D845.3040207@katch.ne.jp>

浦本です。

Tatsuo Ishii wrote:
> 石井です．
> 
>>浦本といいます。
>>
>>sorako yamamoto wrote:
>>
>>>Mashikiさんのご回答で思ったのですが、postgresには、inteｒval型があるんですね
>>>…
>>
>>interval 型は、SQL99 から導入されたデータ型です。
>>そのため、まだ実装されていない RDBMS もあるでしょう。
> 
> interval 型は SQL92 ですでに定義されていますよ．つまり10年以上前からあ
> るわけです．いまだにサポートしていない RDBS があるとしたら，それはちょっ
> と怠慢なのでは:-)

あぅ、そうだったのですか。(汗
知りませんでした。

前述の書籍「SQLクリックリファレンス」の
 1.3.2 追加機能パッケージ
という項で、 SQL99追加機能パッケージ・ID PKG001 という
ところに、「インターバルデータ型」と書いてあったので、
interval は SQL99 での追加項目だと思っていました。

考えてみたら、「地球滅亡まであと＊日」とか、「日食が
始まるまであと＊分」という表現は日常的(？)に使いますね。

そのような一般表現が SQL92 の頃に定義されていないのは
おかしいですね。

勉強になりました。



From fkit.s ＠ sys238.jp  Thu May  8 13:14:19 2003
From: fkit.s ＠ sys238.jp (fumiyaKitamura)
Date: Thu, 8 May 2003 13:14:19 +0900
Subject: [pgsql-jp: 29811] Re: 再起的にデータ数をカウントするには
In-Reply-To: <D26769C4-8107-11D7-B7C1-000393C7A1A2@sys238.jp>
Message-ID: <8A50CDEA-810B-11D7-B7C1-000393C7A1A2@sys238.jp>

キタムラです。

すんません、「再帰的」が抜けていました。これじゃダメですね。

階層数を制限すればSQLで書けるように思いますが、制限なしだと
できるかな？私なら呼び出し元のプログラムで記述します。


*データ登録時に部署の関連がループしないようにする工夫も必要ですね。



On 2003.5.8, at 12:47 Asia/Tokyo, fumiyaKitamura wrote:

> select
> 　b.部署＿ｃｄ,count(*)
> from
>   部門 as b, 社員 as s
> where
>   b.部署＿ｃｄ = s.所属部署＿ｃｄ
> group by
>   b.部署＿ｃｄ
>
> とか、
>
> select
> 　b.親部署＿ｃｄ,count(*)
> from
>   部門 as b, 社員 as s
> where
>   b.部署＿ｃｄ = s.所属部署＿ｃｄ
> group by
>   b.親部署＿ｃｄ
>
> と言うのではダメですか？

=================<F.Kitamura>=================
E-Mail  : fkit ＠ sys238.jp
---
The greatest enemy of man is alcohol.
But, The Bible tells us to love our enemy.
==============================================



From sakata.tetsuo ＠ lab.ntt.co.jp  Thu May  8 13:20:05 2003
From: sakata.tetsuo ＠ lab.ntt.co.jp (Tetsuo SAKATA)
Date: Thu, 08 May 2003 13:20:05 +0900
Subject: [pgsql-jp: 29812] 再起的にデータ数をカウントするには？
References: <8F93121A-80F3-11D7-A775-0003938C6262@digicom.dnp.co.jp>
Message-ID: <3EB9DAF5.82DA9C50@lab.ntt.co.jp>

こんにちは．坂田と申します．

以下の形の問い合わせは，recursive query(再帰問いあわせ)と呼ばれていて，

・部署の階層が任意段ある

のであれば，通常のSQL*だけでは，全ての答えを得る問い合わせを
書くことは出来なかったと思います．

*通常のSQL=SQL2のレベルで，と考えて下さい．

ご参考まで．

> 例えば...
> ┌───────┐
> │部署　　　　　│
> ┝━━━━━━━┥
> │部署＿ｃｄ　　│≪┐≪┐
> │部署名　　　　│　│　│
> │親部署＿ｃｄ　│＜┘　│
> └───────┘　　　│
> ┌───────┐　　　│
> │社員　　　　　│　　　│
> ┝━━━━━━━┥　　　│
> │氏名　　　　　│　　　│
> │所属部署＿ｃｄ│≪──┘
> └───────┘
> というテーブルがあったとして、
> ある部署以下の「のべ社員数」を求めるにはどのようなSQL文を書けばよいのでしょうか。。

-- 
	NTT サイバースペース研究所	sakata.tetsuo ＠ lab.ntt.co.jp
	坂田　哲夫			Tel: 046-859-2765
					Fax: 046-859-2768


From chibacchi ＠ mb.infosnow.ne.jp  Thu May  8 13:46:05 2003
From: chibacchi ＠ mb.infosnow.ne.jp (Hisashi Chiba)
Date: Thu, 8 May 2003 13:46:05 +0900
Subject: [pgsql-jp: 29813] Re: postmaster が再起動不能
References: <011001c31516$651b2f10$7d334a87@PHOBOS>
Message-ID: <012601c3151c$bdb21ca0$7d334a87@PHOBOS>

千葉です。

先ほど、再起動が出来ないのでマシン本体を再起動させたところ
postmaster 自体は起動する事が出来ました。

しかし、問題のところはやはり同じメッセージが表示されます。

$ psql -d db -c "copy table from '/home/postgres/data/datafile.euc'
delimiters ',';"
psql: FATAL 1:  XLogFlush: request A/C4CCA370 is not satisfied --- flushed
only to A/C40E3194

XLogFlush というキーワードはどの様なときに表示されるのでしょう？
データが壊れているからこの様になるのでしょうか。
それとも、システム設定、もしくはファイルが溢れているためでしょうか。

作業としてはデータのリカバリなのですが、先に進む事が出来なく
お手上げ状態です。



From hyoshiok ＠ miraclelinux.com  Thu May  8 13:55:50 2003
From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka)
Date: Thu, 08 May 2003 13:55:50 +0900
Subject: [pgsql-jp: 29814] Re: SMP及びCPU の効果
In-Reply-To: <20030508112228.FCC8.ISHIKAWA-T@comtecc.net>
References: <20030508112228.FCC8.ISHIKAWA-T@comtecc.net>
Message-ID: <20030508135550D.hyoshiok@miraclelinux.com>

よしおかと申します。

わたし自身PostgreSQLについて実務経験が豊富というわけではなく、単なる通り
すがりの者なんですが、それをおふくみおきの上聞いてほしいのですが

> 石川と申します。
> 
> 現在
> 　　ReadHat linux 8.0

なぜ、RedHatなどと言うサポートがすぐに切れるOSを使うのだ
というつっこみはおいておいて…

> 　　PostgreSQL 7.3.2
> 　　メモリー　２G
> の構成を予定しているシステムを設計していますが、動作ハードの選定で質問さ
> せてください。
> 
> １．CPUは、Pentinum IIIとXeonでどの程度パフォーマンスの違いが出るのでしょ
> 　　うか？

個人的な趣味から言えば、Xeonです。Xeonであれば、メモリプロファイリングツー
ル(宣伝)が動いて性能向上のたすけになります。

> ２．CPU１個と２個では、どの程度パフォーマンスの違いが出るのでしょうか？

わたしも非常〜に興味があります。

PostgreSQLのコードをざざっと斜め読みした限りでは、SMPに対してのスケーラ
ビリティが、それほどあるとは思えません。(違っていたら、どなたか指摘して
ください)

pgbenchを流す程度の負荷なんですが(ベンチマークが悪いのかもしれないけれど)
ロックのコンテンションがボトルネックになっていたりして、あんまりスケール
しない感じです。

大規模な実験をする環境を持っていないので、あくまでわたしの予想なのですが、
ディスクをばんばん使って、十分IOバンド幅をそなえた環境で、CPUを1/2/4/8な
どと増加させていった時のスケーラビリティに関しては、ロックのコンテンショ
ン等の問題もあり、それほど性能が出ないのではないかと思っています。(どう
でしょうか？＞識者の皆様)

パラレルクエリみたいなある程度の粒度を持った並列化もしていないようなので
スピードアップもあんまり期待できないような気がしていますが、定量的なデー
タを持っているわけではないですが。

> ３．CPUの個数よりもメモリーの追加（３G又は４G）の方がパフォーマンス向上
> 　　の効果があるのでしょうか？

メモリに関しては、IA-32の場合、64GBまで拡張可能なんですが、すぐに限界が
くるのは目にみえているので、そうなると64ビットCPUということなんですが、
PostgreSQLの64ビット化とか、VLM (Very Large Memory)対応とかはどうなんで
しょうか？

> 上記　３点を基にハードの選定を行いたいと考えています。

参考になるような意見でなくてごめんなさい。

よ
--
Hiro Yoshioka/CTO, Miracle Linux
mailto:hyoshiok ＠ miraclelinux.com
http://www.miraclelinux.com
今月の目標：バグフィックス


From snaga ＠ snaga.org  Thu May  8 14:18:11 2003
From: snaga ＠ snaga.org (Satoshi Nagayasu)
Date: Thu, 8 May 2003 14:18:11 +0900
Subject: [pgsql-jp: 29815] Re: SMP及びCPU  の効果
In-Reply-To: <20030508135550D.hyoshiok@miraclelinux.com>
References: <20030508112228.FCC8.ISHIKAWA-T@comtecc.net>
	<20030508135550D.hyoshiok@miraclelinux.com>
Message-ID: <20030508141811.569d8c90.snaga@snaga.org>

永安です。

Hiro Yoshioka <hyoshiok ＠ miraclelinux.com> wrote:
> PostgreSQLのコードをざざっと斜め読みした限りでは、SMPに対してのスケーラ
> ビリティが、それほどあるとは思えません。(違っていたら、どなたか指摘して
> ください)
> 
> pgbenchを流す程度の負荷なんですが(ベンチマークが悪いのかもしれないけれど)
> ロックのコンテンションがボトルネックになっていたりして、あんまりスケール
> しない感じです。

以前、HACKERS で quad な AIX でパフォーマンスが出ないです、的な
post を見た記憶がありますが、詳しく憶えてません。

ロックの競合ももちっと定量的に測りたいのですが、全然ヒマがありません。

> 大規模な実験をする環境を持っていないので、あくまでわたしの予想なのですが、
> ディスクをばんばん使って、十分IOバンド幅をそなえた環境で、CPUを1/2/4/8な
> どと増加させていった時のスケーラビリティに関しては、ロックのコンテンショ
> ン等の問題もあり、それほど性能が出ないのではないかと思っています。(どう
> でしょうか？＞識者の皆様)

どなたか、32 CPUのIAサーバを貸してください。12〜24時間くらい。B-)

> > ３．CPUの個数よりもメモリーの追加（３G又は４G）の方がパフォーマンス向上
> > 　　の効果があるのでしょうか？

PostgreSQLはバッファの使い方があまりうまくないので、共有バッファを増やしても、
あまりスケールしないという話を以前聞きました。

> メモリに関しては、IA-32の場合、64GBまで拡張可能なんですが、すぐに限界が
> くるのは目にみえているので、そうなると64ビットCPUということなんですが、
> PostgreSQLの64ビット化とか、VLM (Very Large Memory)対応とかはどうなんで
> しょうか？

頭の片隅には常にありますが、今は目の前のタスクを片付けるので精一杯です。
サーベイその他諸々はボチボチと進めてます。

-- 
NAGAYASU Satoshi <snaga ＠ snaga.org>



From t-ishii ＠ sra.co.jp  Thu May  8 16:44:26 2003
From: t-ishii ＠ sra.co.jp (Tatsuo Ishii)
Date: Thu, 08 May 2003 16:44:26 +0900 (JST)
Subject: [pgsql-jp: 29816] Re: SMP及びCPU の効果
In-Reply-To: <20030508135550D.hyoshiok@miraclelinux.com>
References: <20030508112228.FCC8.ISHIKAWA-T@comtecc.net>
	<20030508135550D.hyoshiok@miraclelinux.com>
Message-ID: <20030508.164426.23011384.t-ishii@sra.co.jp>

石井です．

> よしおかと申します。
> 
> わたし自身PostgreSQLについて実務経験が豊富というわけではなく、単なる通り
> すがりの者なんですが、それをおふくみおきの上聞いてほしいのですが

お，よしおかさんじゃないですか．今月の日経Linuxによしおかさんの
hardmeterがしっかり紹介されていましたね．

> > 　　ReadHat linux 8.0
> 
> なぜ、RedHatなどと言うサポートがすぐに切れるOSを使うのだ
> というつっこみはおいておいて…

御意:-)

> > ２．CPU１個と２個では、どの程度パフォーマンスの違いが出るのでしょうか？
> 
> わたしも非常〜に興味があります。
> 
> PostgreSQLのコードをざざっと斜め読みした限りでは、SMPに対してのスケーラ
> ビリティが、それほどあるとは思えません。(違っていたら、どなたか指摘して
> ください)
> 
> pgbenchを流す程度の負荷なんですが(ベンチマークが悪いのかもしれないけれど)
> ロックのコンテンションがボトルネックになっていたりして、あんまりスケール
> しない感じです。

そうなんですよね．

> 大規模な実験をする環境を持っていないので、あくまでわたしの予想なのですが、
> ディスクをばんばん使って、十分IOバンド幅をそなえた環境で、CPUを1/2/4/8な
> どと増加させていった時のスケーラビリティに関しては、ロックのコンテンショ
> ン等の問題もあり、それほど性能が出ないのではないかと思っています。(どう
> でしょうか？＞識者の皆様)

OLTP系の処理では1 CPU -> 2 CPUの効果は絶大です．2 -> 4 はあまり効果な
いです．それ以上の CPU 数は IA アーキテクチャでは試したことないな...

後，トランザクションログ用のディスクを別にするのもかなり効果があります．

> パラレルクエリみたいなある程度の粒度を持った並列化もしていないようなので
> スピードアップもあんまり期待できないような気がしていますが、定量的なデー
> タを持っているわけではないですが。

それはあんまり関係ないのではないでしょうか．

> > ３．CPUの個数よりもメモリーの追加（３G又は４G）の方がパフォーマンス向上
> > 　　の効果があるのでしょうか？
> 
> メモリに関しては、IA-32の場合、64GBまで拡張可能なんですが、すぐに限界が
> くるのは目にみえているので、そうなると64ビットCPUということなんですが、
> PostgreSQLの64ビット化とか、VLM (Very Large Memory)対応とかはどうなんで
> しょうか？

64ビットはすでに対応していると思います．

ただ，搭載メモリ量は多い方がいいですね．PostgreSQLはファイルシステムの
上にデータベースを載っけているので，メモリに余裕があれば，カーネルのバッ
ファリングにかなり助けられます．

> > 上記　３点を基にハードの選定を行いたいと考えています。
> 
> 参考になるような意見でなくてごめんなさい。

同じ．
--
Tatsuo Ishii


From Toshitaka.Iso ＠ hp.com  Thu May  8 16:53:05 2003
From: Toshitaka.Iso ＠ hp.com (Iso, Toshitaka)
Date: Thu, 8 May 2003 16:53:05 +0900
Subject: [pgsql-jp: 29817] SELECTプロセスの自動消去は出来ませんか？
Message-ID: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E021CC8A0@tkoexc02.asiapacific.cpqcorp.net>

こんにちは。

以下の構成でWebアプリケーションを作成しています。

OS：Redhat7.2J
DB：PostgreSQL 7.2.1
Webサーバ：Apache 1.3.26/Tomcat 4.0.6

Web上で検索中にIEの×ボタンを押した場合、
以下のようにSELECTのプロセスが残ってしまいパフォーマンスに影響が出てしまっています。

>> ps auxw | grep SELECT
postgres 18824  5.9  3.9 165328 153564 ?     S    13:13  12:52 postgres: postgres DB01 XX.XX.XX.XX SELECT
postgres 18904  5.6  3.9 165308 153484 ?     S    13:13  12:14 postgres: postgres DB01 XX.XX.XX.XX SELECT
postgres 18914  5.8  3.9 165324 153544 ?     R    13:13  12:41 postgres: postgres DB01 XX.XX.XX.XX SELECT
postgres 18936  5.7  3.9 165292 153488 ?     S    13:13  12:16 postgres: postgres DB01 XX.XX.XX.XX SELECT
postgres 20421  6.1  3.9 165324 153592 ?     D    13:21  12:41 postgres: postgres DB01 XX.XX.XX.XX SELECT
postgres 20794  5.6  3.9 165312 153560 ?     S    13:23  11:35 postgres: postgres DB01 XX.XX.XX.XX SELECT
postgres 20795  5.7  3.9 165324 153576 ?     S    13:23  11:48 postgres: postgres DB01 XX.XX.XX.XX SELECT

以下のプロセスはだいぶ時間が経っているときに取得した結果ですが、
これらのプロセスがCPU/Memoryを圧迫してしまっています。

この残ってしまっているSELECTプロセスを自動的に消去することは出来ないのでしょうか？
PostgreSQLの設定で出来なければ違う方法でやられている方がいらしたらご教授いただけたら幸いです。

以上です。


From chibacchi ＠ mb.infosnow.ne.jp  Thu May  8 17:05:13 2003
From: chibacchi ＠ mb.infosnow.ne.jp (Hisashi Chiba)
Date: Thu, 8 May 2003 17:05:13 +0900
Subject: [pgsql-jp: 29818] Re: postmaster が再起動不能
References: <011001c31516$651b2f10$7d334a87@PHOBOS> <012601c3151c$bdb21ca0$7d334a87@PHOBOS>
Message-ID: <013a01c31538$8f46f590$7d334a87@PHOBOS>

千葉です。

マシン再起動後は、 psql でログイン出来ていたのですが、
vacuumを実行すると、例のエラーメッセージが出てそれ以後使用不能になってしまい
ました。

db=# vacuum;
ERROR:  XLogFlush: request A/C437C634 is not satisfied --- flushed only to
A/C4371B50
db=# \q

その後、sh プロンプトから実行してもエラーとなる状態が続いています。
$ psql -d db -c "vacuum;"
psql: FATAL 1:  XLogFlush: request A/C439A560 is not satisfied --- flushed
only to A/C4371B50
$

どうしたら良いでしょう？



From goto ＠ yokogawa-kouji.co.jp  Thu May  8 18:35:24 2003
From: goto ＠ yokogawa-kouji.co.jp (goto ＠ yokogawa-kouji.co.jp)
Date: Thu, 08 May 2003 18:35:24 +0900 (JST)
Subject: [pgsql-jp: 29819] Re: postmaster が再起動不能
In-Reply-To: <013a01c31538$8f46f590$7d334a87@PHOBOS>
References: <011001c31516$651b2f10$7d334a87@PHOBOS>
	<012601c3151c$bdb21ca0$7d334a87@PHOBOS>
	<013a01c31538$8f46f590$7d334a87@PHOBOS>
Message-ID: <20030508.183524.74758296.goto@debian2>

はじめまして後藤です。

http://archives.postgresql.org/pgsql-bugs/2002-07/msg00150.php

が参考になるのではないでしょうか。以下のようなことらしいです。

  > ERROR:  XLogFlush: request 0/6173A2D8 is not satisfied --- flushed only to 0/616E519C

  This suggests a corrupted LSN on some disk page, but without any context
  I can't say more than that.



From: "Hisashi Chiba" <chibacchi ＠ mb.infosnow.ne.jp>
Subject: [pgsql-jp: 29818] Re: postmaster が再起動不能
Date: Thu, 8 May 2003 17:05:13 +0900

> 
> db=# vacuum;
> ERROR:  XLogFlush: request A/C437C634 is not satisfied --- flushed only to
> A/C4371B50
> db=# \q
> 









From chibacchi ＠ mb.infosnow.ne.jp  Thu May  8 19:01:14 2003
From: chibacchi ＠ mb.infosnow.ne.jp (Hisashi Chiba)
Date: Thu, 8 May 2003 19:01:14 +0900
Subject: [pgsql-jp: 29820] Re: postmaster が再起動不能
References: <011001c31516$651b2f10$7d334a87@PHOBOS><012601c3151c$bdb21ca0$7d334a87@PHOBOS><013a01c31538$8f46f590$7d334a87@PHOBOS> <20030508.183524.74758296.goto@debian2>
Message-ID: <016601c31548$c327cd20$7d334a87@PHOBOS>

> はじめまして後藤です。

こちらこそ、初めまして。千葉です。今後ともよろしくお願いします。

> http://archives.postgresql.org/pgsql-bugs/2002-07/msg00150.php
>
> が参考になるのではないでしょうか。以下のようなことらしいです。
>
>   > ERROR:  XLogFlush: request 0/6173A2D8 is not satisfied --- flushed
only to 0/616E519C
>
>   This suggests a corrupted LSN on some disk page, but without any context
>   I can't say more than that.

これを見て、なるほどと思いました。
最初に再起動したときネットワーク越しにリモートで再起動していたので、起動時の
メッセージは
見ていなかったので判りませんでしたが、今、もう一度マシンの再起動をして起動時
のメッセージ
を見ていると、一部のパーティションでエラーが出ていました。

どうやらディスクがクラッシュした様で、このままでは継続使用は出来なという事で
すね。
ディスクの交換か、マシンの入れ替えが必要という事態になってしまい、とまどって
います。
勤務先で使用しているＰＣサーバーですが、補助用ではありますが業務で使われてい
て、
代替機が無いのでデータの移行は何が良いのか、悩んでしまいます。

何れにしろ原因がわかりましたので、大変助かりました。有り難うございます。



From sakata.tetsuo ＠ lab.ntt.co.jp  Thu May  8 19:12:16 2003
From: sakata.tetsuo ＠ lab.ntt.co.jp (Tetsuo SAKATA)
Date: Thu, 08 May 2003 19:12:16 +0900
Subject: [pgsql-jp: 29821] Re: postmaster が再起動不能
References: <011001c31516$651b2f10$7d334a87@PHOBOS> <012601c3151c$bdb21ca0$7d334a87@PHOBOS>
Message-ID: <3EBA2D80.906C08C8@lab.ntt.co.jp>

こんにちは，坂田@横須賀です．

Hisashi Chiba wrote:
> しかし、問題のところはやはり同じメッセージが表示されます。
> 
> $ psql -d db -c "copy table from '/home/postgres/data/datafile.euc'
> delimiters ',';"
> psql: FATAL 1:  XLogFlush: request A/C4CCA370 is not satisfied --- flushed
> only to A/C40E3194
> 
> XLogFlush というキーワードはどの様なときに表示されるのでしょう？

このメッセージですが，更新結果をログに結果を書き出す(flush)する際に，
ログが壊れていると出るもののようです．
(...と書いていたら，後藤さんのメールが来ましたね)

Xlog.cというソースにある，XLogFlush という関数が
上記のエラーメッセージを出しているようです．
そこの注釈を見ると，どう言う状況でこのエラーを出すかが
書かれているのですが，イマイチ理解できていません．
(ログは順序良く書き出さないとマズイのですが，後から書き出すべき
内容を既に書き出してしまっている，という状況のようです)

事情が許せば，データベースを(initdbで)作りなおすのが
良いのではないかと思うのですが...

#参考にならなくて済みません．
-- 
	NTT サイバースペース研究所	sakata.tetsuo ＠ lab.ntt.co.jp
	坂田　哲夫			Tel: 046-859-2765
					Fax: 046-859-2768


From Toshitaka.Iso ＠ hp.com  Thu May  8 20:07:11 2003
From: Toshitaka.Iso ＠ hp.com (Iso, Toshitaka)
Date: Thu, 8 May 2003 20:07:11 +0900
Subject: [pgsql-jp: 29822] Re: SELECTプロセスの自動消去は出来ませんか？
Message-ID: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E0234062A@tkoexc02.asiapacific.cpqcorp.net>

たびたびすみません。
追加で分かったことがありました。

SELECTのプロセスだけでなく、idle in transactionの状態のものがCPUを多く使っている
ことが分かりました。

PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
7869 postgres  11   0  150M 150M  148M R       71.9   3.9       7:36   postmaster

[ServerName]$ ps auxww | grep 7869
postgres  7869  2.8  3.9 165880 153712 ?     S    15:35   7:43 postgres: postgres DBNAME XX.XX.XX.XX idle in transaction

このような現象が起きた事がある方、対処法をご存知の方、ぜひともご教授下さい。

よろしくお願いいたします。

>  -----Original Message-----
> From: 	Iso, Toshitaka  
> Sent:	Thursday, May 08, 2003 4:53 PM
> To:	pgsql-jp ＠ ml.postgresql.jp
> Subject:	SELECTプロセスの自動消去は出来ませんか？
> 
> こんにちは。
> 
> 以下の構成でWebアプリケーションを作成しています。
> 
> OS：Redhat7.2J
> DB：PostgreSQL 7.2.1
> Webサーバ：Apache 1.3.26/Tomcat 4.0.6
> 
> Web上で検索中にIEの×ボタンを押した場合、
> 以下のようにSELECTのプロセスが残ってしまいパフォーマンスに影響が出てしまっています。
> 
> >> ps auxw | grep SELECT
> postgres 18824  5.9  3.9 165328 153564 ?     S    13:13  12:52 postgres: postgres DB01 XX.XX.XX.XX SELECT
> postgres 18904  5.6  3.9 165308 153484 ?     S    13:13  12:14 postgres: postgres DB01 XX.XX.XX.XX SELECT
> postgres 18914  5.8  3.9 165324 153544 ?     R    13:13  12:41 postgres: postgres DB01 XX.XX.XX.XX SELECT
> postgres 18936  5.7  3.9 165292 153488 ?     S    13:13  12:16 postgres: postgres DB01 XX.XX.XX.XX SELECT
> postgres 20421  6.1  3.9 165324 153592 ?     D    13:21  12:41 postgres: postgres DB01 XX.XX.XX.XX SELECT
> postgres 20794  5.6  3.9 165312 153560 ?     S    13:23  11:35 postgres: postgres DB01 XX.XX.XX.XX SELECT
> postgres 20795  5.7  3.9 165324 153576 ?     S    13:23  11:48 postgres: postgres DB01 XX.XX.XX.XX SELECT
> 
> 以下のプロセスはだいぶ時間が経っているときに取得した結果ですが、
> これらのプロセスがCPU/Memoryを圧迫してしまっています。
> 
> この残ってしまっているSELECTプロセスを自動的に消去することは出来ないのでしょうか？
> PostgreSQLの設定で出来なければ違う方法でやられている方がいらしたらご教授いただけたら幸いです。
> 
> 以上です。


From chibacchi ＠ mb.infosnow.ne.jp  Thu May  8 20:41:04 2003
From: chibacchi ＠ mb.infosnow.ne.jp (Hisashi Chiba)
Date: Thu, 8 May 2003 20:41:04 +0900
Subject: [pgsql-jp: 29823] Re: postmaster が再起動不能
References: <011001c31516$651b2f10$7d334a87@PHOBOS> <012601c3151c$bdb21ca0$7d334a87@PHOBOS> <3EBA2D80.906C08C8@lab.ntt.co.jp>
Message-ID: <018801c31556$b5a1b3b0$7d334a87@PHOBOS>

千葉です。

坂田さん、有り難うございます。

> このメッセージですが，更新結果をログに結果を書き出す(flush)する際に，
> ログが壊れていると出るもののようです．

ここらへんは、後藤さんへの返信にも書きましたが、ディスクがイカレたらしく、
それでログが壊れてしまっているのではないでしょうか。
エラー発症当初は、何が原因かさっぱり判らず、リプライもつかなかったので
結構あせっていました。

> (ログは順序良く書き出さないとマズイのですが，後から書き出すべき
> 内容を既に書き出してしまっている，という状況のようです)

状況によっては、バックエンドがこの様に捉えてしまうのかも知れないのでしょう。
（システムについては、全くの素人ですが。）

> 事情が許せば，データベースを(initdbで)作りなおすのが
> 良いのではないかと思うのですが...

リカバリーの方法を検討してみます。

色々有り難うございました。



From ohr ＠ yoursys.org  Thu May  8 22:12:52 2003
From: ohr ＠ yoursys.org (ohara takaaki)
Date: Thu, 08 May 2003 22:12:52 +0900
Subject: [pgsql-jp: 29824] text型にinsertするとpg_atoiエラーが
Message-ID: <20030508215336.F92D.OHR@yoursys.org>

はじめて投稿します：
ohr といいます．よろしくお願いします．
FAQだと思いいろいろ調べているのですが，
よくわからないので助言をいただきたいと思い
投稿させてもらいました．

php スクリプトから変数 $textCode を使って以下のような
SQL 分をつくり，pg_exec に渡しています．
table1 の textCode フィールドはテキストになっています．

$textCode = 'str010101954';
$sql = "INSERT INTO table1(someflg, textCode) VALUES(0,'$textCode')";
pg_exec($con, $sql);

とすると，
Warning: pg_exec() query failed: ERROR: pg_atoi: error in
"str010101954": can't parse "str010101954" in ・・・

上記エラーが出ます．
table1 は
someflg  | smallint |
code     | integer  | not null default nextval('"morder_code_seq"'::text)
textcode | text     |

のような感じです．

なぜ pg_atoi のエラーがでるのか分かりません．
アドバイスいただきたいです．


-- 
ohara takaaki <ohr ＠ yoursys.org>



From sorako_y ＠ hotmail.com  Fri May  9 10:07:51 2003
From: sorako_y ＠ hotmail.com (sorako yamamoto)
Date: Fri, 09 May 2003 01:07:51 +0000
Subject: [pgsql-jp: 29825] Re: int型の分をhh:ii 形式に直す方法
Message-ID: <Law15-F62DEJmGzrLCC0000a2d3@hotmail.com>

やまもとです。

>「SQLクリックリファレンス」

参考にしたいと思います。

Postgresだけでなく、SQLについても精進します。

どうもありがとうございました。


やまもとそらこ。

_________________________________________________________________
キャリアアップを目指すあなたのナビゲーター MSN 就職・転職   
http://career.msn.co.jp/  



From mochizuki ＠ adcoop.co.jp  Fri May  9 12:08:17 2003
From: mochizuki ＠ adcoop.co.jp (Takashi Mochizuki)
Date: Fri, 09 May 2003 12:08:17 +0900
Subject: [pgsql-jp: 29826] Re: text型にinsert するとpg_atoiエラーが
In-Reply-To: <20030508215336.F92D.OHR@yoursys.org>
References: <20030508215336.F92D.OHR@yoursys.org>
Message-ID: <20030509120534.6507.MOCHIZUKI@adcoop.co.jp>

望月です。

たぶん、

$sql = "INSERT INTO table1(someflg,code, textCode)VALUES(0,nextval('code'),'$textCode')";

だったと思います。

参照URL

http://www.postgresql.jp/document/pg653doc/ej/user/sql-createsequence.htm


From ohr ＠ yoursys.org  Fri May  9 12:33:38 2003
From: ohr ＠ yoursys.org (ohara takaaki)
Date: Fri, 09 May 2003 12:33:38 +0900
Subject: [pgsql-jp: 29827] Re: text型にinsert  するとpg_atoiエラーが
In-Reply-To: <20030509120534.6507.MOCHIZUKI@adcoop.co.jp>
References: <20030508215336.F92D.OHR@yoursys.org> <20030509120534.6507.MOCHIZUKI@adcoop.co.jp>
Message-ID: <20030509123141.E6FC.OHR@yoursys.org>

ohr です．
望月さんありがとうございます．
早速試してみます．

# serial 型のところは他の sql でも
# 省略していてエラーは出ないのですが・・・

> 
> $sql = "INSERT INTO table1(someflg,code, textCode)VALUES(0,nextval('code'),'$textCode')";
> 
> だったと思います。

-- 
ohara takaaki <ohr ＠ yoursys.org>



From shiina.yasutada ＠ tohoku.ns-sol.co.jp  Fri May  9 13:01:06 2003
From: shiina.yasutada ＠ tohoku.ns-sol.co.jp (椎名　靖忠)
Date: Fri, 9 May 2003 13:01:06 +0900
Subject: [pgsql-jp: 29828] システム構築後にカラム名称の長さの設定を変更する方法について
Message-ID: <003101c315df$9d9d06f0$8efc1cac@YSHIINA>

椎名です。
お世話になります。

以下、ご回答を頂きたくお願いいたします。

１．ご回答頂きたい内容
　　現在テーブルのカラム名が２６文字迄使用可能で、
　　２７文字目から切り捨てられている現象が発生しております。

　　これに関して以下のURLで確認したところ、
　　最長３１文字迄可能であるとの記述がありました。

　　-----------以下、記述部分------------　　

　　対象URL
　　http://osb.sra.co.jp/PostgreSQL/Manual/PostgreSQL-7.1-ja/sql-syntax.html

　　1.1.1. 識別子とキーワード
　　デフォルトではNAMEDATALEN は 32 なので、識別子の最長は 31 です
　　(しかしシステムが構築される 時にNAMEDATALENという名前は
　　 src/include/postgres_ext.hで変えることが できます。）

　　-----------ここまで------------　　

　　記述では、システムを構築する時は、postgres_ext.hファイルの設定で、
　　カラム名の長さを変更できる様ですが、
　　RedHat Linux8.0　に　PostgreSQL 7.2.2　をrpmインストールしたためか、
　　記述内の　postgres_ext.h　ファイルはありませんでした。

　　システムを構築してしまってからカラム名の長さを変更する方法はありますか？
　　基本、最大長にすると上記現象は避けられると考えています。
　　確認方法と変更方法をご教授下さい。

　　以上、宜しくお願いいたします。



From mkoban ＠ momijic.office.ne.jp  Fri May  9 15:22:18 2003
From: mkoban ＠ momijic.office.ne.jp (mkoban ＠ momijic.office.ne.jp)
Date: Fri, 09 May 2003 15:22:18 +0900
Subject: [pgsql-jp: 29829] Re: SELECTプロセスの自動消去は出来ませんか？
In-Reply-To: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E0234062A@tkoexc02.asiapacific.cpqcorp.net>
References: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E0234062A@tkoexc02.asiapacific.cpqcorp.net>
Message-ID: <E9C315F357682Emkoban@momijic.office.ne.jp>

お疲れ様です。小林と言います。

●ピンポイントではないです。

最近、似た現象が発生しました。(RedHat8.0/PostgreSQL7.3.1/tomcat4.1.18)
postgres: xxx db_xxx X.X.X.X idle in transaction
postgres: xxx db_xxx X.X.X.X SELECT waiting
postgres: xxx db_xxx X.X.X.X SELECT waiting
:

[pgsql-jp: 29242]からのスレッドを参考にLockしているテーブルを特定しまし
た。「in transaction」のスレッドが確か「AccessExclusiveLock」してて、
「SELECT waiting」のスレッドは「AccessShareLock」待ちの状態でした。

PostgreSQLの設定でLock待ちのタイムアウトの設定はできるかなと思って探した
のですが見つかりませんでした。

大元の原因である「in transaction」でLockを解除しないプログラムを見直した
ところ、transactionに入ったあと、（バグですが）ある条件で無限ループに陥
るようで、そちらの対応を施すことにより同現象は発生しなくなりました。（な
くなったようです．．．）

と、言うことで「in transaction」のまま「commit/rollback」しない原因を
（PostgreSQLのログやLockしているテーブルなどから）探すしかないのかなーな
んて思いました。「SELECTプロセスの自動消去」の方法は分からずです。（私の
場合．．．内緒ですが．．．頭に来てkillしてしまいました。）

あんまり役立ちそうでもないですね．．．でも少しでもお役に立てれば幸いです。

よろしくお願いします。

in "[pgsql-jp: 29822] Re: SELECTプロセスの自動消去は出来ませんか？" "Iso, 
Toshitaka" <Toshitaka.Iso ＠ hp.com> [Thu, 8 May 2003 20:07:11 +0900] 
wrote:

---- snip ----
>SELECTのプロセスだけでなく、idle in transactionの状態のものがCPUを多く使っている
>ことが分かりました。
>
>PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
>7869 postgres  11   0  150M 150M  148M R       71.9   3.9       7:36   postmaster
>
>[ServerName]$ ps auxww | grep 7869
>postgres  7869  2.8  3.9 165880 153712 ?     S    15:35   7:43 postgres: postgres DBNAME XX.XX.
>XX.XX idle in transaction
>
>このような現象が起きた事がある方、対処法をご存知の方、ぜひともご教授下さい。

---- snip ----

>> Web上で検索中にIEの×ボタンを押した場合、
>> 以下のようにSELECTのプロセスが残ってしまいパフォーマンスに影響が出てしまっています。
>> 
>> >> ps auxw | grep SELECT
>> postgres 18824  5.9  3.9 165328 153564 ?     S    13:13  12:52 postgres: postgres DB01 XX.XX.
>> XX.XX SELECT

---- snip ----

>> この残ってしまっているSELECTプロセスを自動的に消去することは出来ないのでしょうか？
>> PostgreSQLの設定で出来なければ違う方法でやられている方がいらしたらご教授いただけたら幸いです。

---- snip ----

-- 
M.Kob


From matchori ＠ yahoo.co.jp  Fri May  9 18:37:42 2003
From: matchori ＠ yahoo.co.jp (Kouichi Matsumoto)
Date: Fri, 9 May 2003 18:37:42 +0900 (JST)
Subject: [pgsql-jp: 29830] 日付範囲内の日付を全て取得したいです
Message-ID: <20030509093742.67087.qmail@web402.mail.yahoo.co.jp>

お世話になっております。松本です。

2003/01/01〜2003/05/10
などの範囲の日付を全て取得するSQLはありますでしょうか？

以下のような結果を取得したいと思います。

2003/01/01
2003/01/02
2003/01/03
・
・
・
2003/05/10

よろしくお願いします。

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!  http://bb.yahoo.co.jp/



From gontakun ＠ fish.co.jp  Fri May  9 18:55:32 2003
From: gontakun ＠ fish.co.jp (Chie.M)
Date: Fri, 09 May 2003 18:55:32 +0900
Subject: [pgsql-jp: 29831] Re: 日付範囲内の日付を全て取得したいです
In-Reply-To: <20030509093742.67087.qmail@web402.mail.yahoo.co.jp>
References: <20030509093742.67087.qmail@web402.mail.yahoo.co.jp>
Message-ID: <20030509185249.F562.GONTAKUN@fish.co.jp>

Chie.Mです。

> 2003/01/01〜2003/05/10
> などの範囲の日付を全て取得するSQLはありますでしょうか？

　BETWEEN ... AND ...
でできませんか？

SELECT * FROM テーブル名 
WHERE 日付のカラム名  BETWEEN '2003-01-01' AND '2003-05-01';

ここにいろいろ出てます↓
http://www.postgresql.jp/document/pg721doc/user/index.html

----------------------------
Chie.M <gontakun ＠ fish.co.jp>



From saito.tetsuo ＠ renesas.com  Fri May  9 19:04:53 2003
From: saito.tetsuo ＠ renesas.com (Saito Tetsuo)
Date: Fri, 09 May 2003 19:04:53 +0900
Subject: [pgsql-jp: 29832] データベースの復旧
Message-ID: <4.2.0.58.J.20030509190451.00a58270@bldl049s.sow.renesas.com>

斉藤と申します。はじめまして。

質問があります。
私が使用していますPostgreSQL 7.2.3を載せているマシンの
環境をシステム管理者の方が変更してしまい、私が使えて
いたデータが参照できなくなりました。システム管理者は、
最近変わったばかりで私がインストールしていたことを認識して
おらず、環境を変更してしまいました。しかも、バックアップを
取っていませんでした。
環境を変更したと言っても、マウントは元のまま。データも
変更しておりません。ですから、何が影響してデータが
参照できなくなったのか原因不明です。
しかし、そこにしかないデータが多いため、どうしても必要です。

現在わかっていることは、以下のとおりです。

・psqlでデータベースを開くことができる。
・SELECTでデータを参照しようとすると、空白で返ってくる。
・実データの格納されているdataディレクトリには、データ容量が
あり、どうやら、実データは存在するらしい。

以上です。非常に情報が少なく、申し訳ありません。
素人ながら、私の知る限りでは調べてみたのですが、
わかりません。おわかりの方がおられましたら、ご教授
お願い致します。 


From gontakun ＠ fish.co.jp  Fri May  9 19:40:44 2003
From: gontakun ＠ fish.co.jp (Chie.M)
Date: Fri, 09 May 2003 19:40:44 +0900
Subject: [pgsql-jp: 29833] Re: データベースの復旧
In-Reply-To: <4.2.0.58.J.20030509190451.00a58270@bldl049s.sow.renesas.com>
References: <4.2.0.58.J.20030509190451.00a58270@bldl049s.sow.renesas.com>
Message-ID: <20030509193322.F56A.GONTAKUN@fish.co.jp>

> ・psqlでデータベースを開くことができる。
> ・SELECTでデータを参照しようとすると、空白で返ってくる。
> ・実データの格納されているdataディレクトリには、データ容量が
> あり、どうやら、実データは存在するらしい。
> 
> 以上です。非常に情報が少なく、申し訳ありません。

少なすぎると思います・・・。
OSもわからないし、どうやって接続してるかもわからないと
答えられないと思います。

PostgresSQLのオーナーやユーザが以前と同じままに
なっているか（権限とか・・・）
システム管理者に確認した方がいいと思います。
また、斉藤さんが使われていたPostgresSQLのオーナやユーザ
がどうなっているか等も確認した方がいいでしょう。

また、リモートで接続しているのならそちらの設定の
確認も必要ですね・・・。

いずれにしても、システム管理者に
ご相談される事をおすすめします。
----------------------------
Chie.M <gontakun ＠ fish.co.jp>



From iakio ＠ pjam.jpweb.net  Fri May  9 20:04:59 2003
From: iakio ＠ pjam.jpweb.net (ISHIDA Akio)
Date: Fri, 9 May 2003 20:04:59 +0900
Subject: [pgsql-jp: 29834] Re: データベースの復旧
In-Reply-To: <4.2.0.58.J.20030509190451.00a58270@bldl049s.sow.renesas.com>
References: <4.2.0.58.J.20030509190451.00a58270@bldl049s.sow.renesas.com>
Message-ID: <20030509200459.7DFA8A90.iakio@pjam.jpweb.net>

こんにちは。石田@苫小牧市です。

Saito Tetsuo <saito.tetsuo ＠ renesas.com> wrote:
(2003/05/09 19:04)

> 斉藤と申します。はじめまして。
(中略)
> 現在わかっていることは、以下のとおりです。
> 
> ・psqlでデータベースを開くことができる。
> ・SELECTでデータを参照しようとすると、空白で返ってくる。
> ・実データの格納されているdataディレクトリには、データ容量が
> あり、どうやら、実データは存在するらしい。

これらは具体的にどういう操作をしてどういう結果が返って
きたのでしょうか？
さしつかえない範囲で、実行したコマンドと結果をコピー&ペースト
して下さい。


--
ISHIDA Akio<iakio ＠ pjam.jpweb.net>



From saimi ＠ oliver.co.jp  Fri May  9 23:57:46 2003
From: saimi ＠ oliver.co.jp (SAIMI Kohei (斎見 浩平))
Date: Fri, 09 May 2003 23:57:46 +0900
Subject: [pgsql-jp: 29835] Re: 日付範囲内の日付を全て取得したいです
In-Reply-To: <20030509093742.67087.qmail@web402.mail.yahoo.co.jp>
References: <20030509093742.67087.qmail@web402.mail.yahoo.co.jp>
Message-ID: <20030509225739.E95D.SAIMI@oliver.co.jp>

> 2003/01/01〜2003/05/10
> などの範囲の日付を全て取得するSQLはありますでしょうか？

1. まず、こんなテーブルを作っときます。

CREATE TABLE _0_to_9 ( n integer PRIMARY KEY );
INSERT INTO _0_to_9 VALUES (0);
INSERT INTO _0_to_9 VALUES (1);
...
INSERT INTO _0_to_9 VALUES (9);

2. 次に、こんなビューを作ります。

CREATE VIEW _0_to_999 AS
  SELECT t0.n + t1.n*10 + t2.n*100 AS n
  FROM _0_to_9 t2, _0_to_9 t1, _0_to_9 t0;
  
SELECT n FROM _0_to_999 ORDER BY n;
  n  
-----
   0
   1
...
 999
(1000 rows)

3. で、例えば、2003/01/01〜2003/05/10が欲しいとき、

SELECT '2003/01/01'::date + n as dates from _0_to_999
WHERE '2003/01/01'::date + n <= '2003/05/10'::date
ORDER BY n;

とやると、

   dates
------------
 2003-01-01
 2003-01-02
 ...
 2003-05-10
(130 rows)

と出力されるはずです。


-- 
SAIMI Kohei (斎見 浩平) <saimi ＠ oliver.co.jp>



From ml ＠ niji-net.com  Sat May 10 07:27:12 2003
From: ml ＠ niji-net.com (Ryuichiro Munechika)
Date: Sat, 10 May 2003 07:27:12 +0900
Subject: [pgsql-jp: 29836] Re: システム構築後にカラム名称の長さの設定を変更する方法について
In-Reply-To: <003101c315df$9d9d06f0$8efc1cac@YSHIINA>
References: <003101c315df$9d9d06f0$8efc1cac@YSHIINA>
Message-ID: <200305092227.AA00367@tiger2k.niji-net.com>

  まいパパです

>　　システムを構築してしまってからカラム名の長さを変更する方法はありますか？
>　　基本、最大長にすると上記現象は避けられると考えています。
>　　確認方法と変更方法をご教授下さい。

　alterコマンドを使ってできませんか。
http://www.postgresql.jp/document/pg721doc/reference/sql-altertable.html

　他のDBMSでも若干文法は異なるもののalterコマンドで変更できると
思います。



From net_info ＠ mb.scn-net.ne.jp  Sat May 10 17:34:23 2003
From: net_info ＠ mb.scn-net.ne.jp (Nobuo Nishino)
Date: Sat, 10 May 2003 17:34:23 +0900
Subject: [pgsql-jp: 29837] intersectの使い方に関して
Message-ID: <IPELKNJLOEFONEEHJAKOCECNCCAA.net_info@mb.scn-net.ne.jp>

西野と申します。

環境
postgresql-7.2.3-5.73
RedHatLinux 2.4.18

create table test
(
     key		integer,
     value	varhar(100),
)

以上のようなテーブルがありデータは以下のようなデータがあるとします。

| key | value |
|   1 |     a |
|   1 |     b |
|   2 |     b |
|   2 |     d |
|   2 |     e |
|   3 |     a |
|   3 |     b |
|   3 |     e |

このようなデータがあるときに
SELECT key FROM test WHERE value = 'a'
intersect
SELECT key FROM test WHERE value = 'b'
と、SQLを実行した結果レコード件数が0件となってしまいます。
（実際にはレコード件数2件でkey = 1と3が戻ると思うのですが ）

個別にSQLを実行したときは・・
SELECT key FROM test WHERE value = 'a'
結果　レコード件数　2件
SELECT key FROM test WHERE value = 'b'
結果　レコード件数　3件
となります。

なぜintersectがうまく動作しないのでしょうか？
初心者ですがご教授お願いいたします。




From nishino ＠ beatup.net  Sat May 10 17:48:45 2003
From: nishino ＠ beatup.net (Nobuo Nishino)
Date: Sat, 10 May 2003 17:48:45 +0900
Subject: [pgsql-jp: 29838] Re: intersectの使い方に関して【自己解決】
In-Reply-To: <IPELKNJLOEFONEEHJAKOCECNCCAA.net_info@mb.scn-net.ne.jp>
Message-ID: <IBEFJCJPPAHNMMFGAJHGAEAICHAA.nishino@beatup.net>

西野です。

投稿しておいてすぐに自己解決なのですが・・・
先ほど、サンプルで書いたSQLに間違いがありました。

実際は
SELECT * FROM test WHERE value = 'a'
intersect
SELECT * FROM test WHERE value = 'b'
で実行していたので、*をkeyに変更したら正しく結果が出ました。
ご迷惑おかけいたしました。





From tak ＠ hdt.co.jp  Sat May 10 17:50:37 2003
From: tak ＠ hdt.co.jp (Takeshi Miyakawa)
Date: Sat, 10 May 2003 17:50:37 +0900
Subject: [pgsql-jp: 29839] Re: intersectの使い方に関して
In-Reply-To: <IPELKNJLOEFONEEHJAKOCECNCCAA.net_info@mb.scn-net.ne.jp>
References: <IPELKNJLOEFONEEHJAKOCECNCCAA.net_info@mb.scn-net.ne.jp>
Message-ID: <3EBCBD5D.9030606@hdt.co.jp>

　みやかわ＠ホビー・データです。

Nobuo Nishino wrote:
>create table test
>(
>     key		integer,
>     value	varhar(100),
>)
>
>以上のようなテーブルがありデータは以下のようなデータがあるとします。
>
>| key | value |
>|   1 |     a |
>|   1 |     b |
>|   2 |     b |
>|   2 |     d |
>|   2 |     e |
>|   3 |     a |
>|   3 |     b |
>|   3 |     e |
>
>このようなデータがあるときに
>SELECT key FROM test WHERE value = 'a'
>intersect
>SELECT key FROM test WHERE value = 'b'
>と、SQLを実行した結果レコード件数が0件となってしまいます。
>（実際にはレコード件数2件でkey = 1と3が戻ると思うのですが ）
　戻りません。

　query_a INTERSECT query_b

　という形式は、query_aとquery_bの双方に現れる「行」を返します。

　このケースでは、SELECT key FROM test WHERE value = 'a' は、
|   1 |     a |
|   3 |     a |

の2行を返します。
　一方、SELECT key FROM test WHERE value = 'b'は、

|   1 |     b |
|   2 |     b |
|   3 |     b |

の3行を返します。
　前者と後者に重複する行はありませんから、INTERSECTは何も戻さ
ないのです。

　ご希望の動作を実現するには、以下のように書くことになるかと思います。

SELECT key
  FROM test
 WHERE value = 'a' AND
       key IN (SELECT key
                 FROM test
                WHERE value = 'b');
 




From aoki-kazuyuki ＠ nifty.com  Sat May 10 17:56:52 2003
From: aoki-kazuyuki ＠ nifty.com (aoki-kazuyuki ＠ nifty.com)
Date: Sat, 10 May 2003 17:56:52 +0900
Subject: [pgsql-jp: 29840] Re: intersectの使い方に関して
References: <IPELKNJLOEFONEEHJAKOCECNCCAA.net_info@mb.scn-net.ne.jp>
Message-ID: <014701c316d2$19eea7c0$0200a8c0@AOKIVAIO>

前略

答えになってないと思いますが、

    SELECT key FROM test WHERE value IN( 'a','b')

これで実現きませんか？

青木




> 西野と申します。
>
> 環境
> postgresql-7.2.3-5.73
> RedHatLinux 2.4.18
>
> create table test
> (
>      key integer,
>      value varhar(100),
> )
>
> 以上のようなテーブルがありデータは以下のようなデータがあるとします。
>
> | key | value |
> |   1 |     a |
> |   1 |     b |
> |   2 |     b |
> |   2 |     d |
> |   2 |     e |
> |   3 |     a |
> |   3 |     b |
> |   3 |     e |
>
> このようなデータがあるときに
> SELECT key FROM test WHERE value = 'a'
> intersect
> SELECT key FROM test WHERE value = 'b'
> と、SQLを実行した結果レコード件数が0件となってしまいます。
> （実際にはレコード件数2件でkey = 1と3が戻ると思うのですが ）
>
> 個別にSQLを実行したときは・・
> SELECT key FROM test WHERE value = 'a'
> 結果　レコード件数　2件
> SELECT key FROM test WHERE value = 'b'
> 結果　レコード件数　3件
> となります。
>
> なぜintersectがうまく動作しないのでしょうか？
> 初心者ですがご教授お願いいたします。
>
>
>




From t-ishii ＠ sra.co.jp  Sat May 10 22:54:49 2003
From: t-ishii ＠ sra.co.jp (Tatsuo Ishii)
Date: Sat, 10 May 2003 22:54:49 +0900 (JST)
Subject: [pgsql-jp: 29841] Re: EXEやバッチの起動について
In-Reply-To: <200305020816.RAA12175@ns.itc-net.co.jp>
References: <200305020816.RAA12175@ns.itc-net.co.jp>
Message-ID: <20030510.225449.85411946.t-ishii@sra.co.jp>

石井です．

> ＥＸＥやバッチを、PL/pgSQLの中で実行させる方法
> （Unix上で動作させる為、できればshellを実行させる方法）
> を探しているのですが、いろいろなサイト、ドキュメント等を見ても、
> それらしきものが載っておらず（読解力がないだけかもしれませんが）、
> ご存知の方がおられましたら、どうかお知恵をお貸しいただけないでしょうか？
> よろしくお願いいたします。

PL/shというのがあります．その名の通り，shell scriptでユーザ定義関数を
書けるものです．

http://www.ca.postgresql.org/~petere/plsh.html

言うまでもありませんが，使い方によってはもろにセキュリティホールになる
ので，気をつけましょう．
--
Tatsuo Ishii


From t-ishii ＠ sra.co.jp  Sat May 10 23:07:54 2003
From: t-ishii ＠ sra.co.jp (Tatsuo Ishii)
Date: Sat, 10 May 2003 23:07:54 +0900 (JST)
Subject: [pgsql-jp: 29842] Re: システム構築後にカラム名称の長さの設定を変更する方法について
In-Reply-To: <003101c315df$9d9d06f0$8efc1cac@YSHIINA>
References: <003101c315df$9d9d06f0$8efc1cac@YSHIINA>
Message-ID: <20030510.230754.39155492.t-ishii@sra.co.jp>

石井です．

> 　　現在テーブルのカラム名が２６文字迄使用可能で、
> 　　２７文字目から切り捨てられている現象が発生しております。
> 
> 　　これに関して以下のURLで確認したところ、
> 　　最長３１文字迄可能であるとの記述がありました。

31「文字」とは書かかれていませんが？ここでの単位は正確には「バイト」で
す．

> 　　-----------以下、記述部分------------　　
> 
> 　　対象URL
> 　　http://osb.sra.co.jp/PostgreSQL/Manual/PostgreSQL-7.1-ja/sql-syntax.html
> 
> 　　1.1.1. 識別子とキーワード
> 　　デフォルトではNAMEDATALEN は 32 なので、識別子の最長は 31 です
> 　　(しかしシステムが構築される 時にNAMEDATALENという名前は
> 　　 src/include/postgres_ext.hで変えることが できます。）
> 
> 　　-----------ここまで------------　　
> 
> 　　記述では、システムを構築する時は、postgres_ext.hファイルの設定で、
> 　　カラム名の長さを変更できる様ですが、
> 　　RedHat Linux8.0　に　PostgreSQL 7.2.2　をrpmインストールしたためか、
> 　　記述内の　postgres_ext.h　ファイルはありませんでした。

RedHatのRPMがどうなっているのか知りませんが，なんで今頃 PostgreSQL
7.2.2をわざわざ使っているのですか？PostgreSQL 7.3.xにすれば，識別子は
デフォルトで64バイトまで使えるようになります．

> 　　システムを構築してしまってからカラム名の長さを変更する方法はありますか？

ありません．DBをバックアップしてからPostgreSQL 7.3.2にして，DBをリスト
アし，ALTER TABLEで列名を変更するのが私としてはお勧めです．
--
Tatsuo Ishii


From yuin ＠ bb.din.or.jp  Sun May 11 02:11:14 2003
From: yuin ＠ bb.din.or.jp (Makoto,Yui)
Date: Sun, 11 May 2003 02:11:14 +0900
Subject: [pgsql-jp: 29843] Re: 再起的にデータ数をカウントするには？
In-Reply-To: <8F93121A-80F3-11D7-A775-0003938C6262@digicom.dnp.co.jp>
References: <8F93121A-80F3-11D7-A775-0003938C6262@digicom.dnp.co.jp>
Message-ID: <20030511021114.13715700.yuin@bb.din.or.jp>

油井です.

任意数の再帰的な問合せだと, GborgにOracleのConnect byに似た
構文サポートのパッチを挙げている人がいました.(PG7.3.1の時, 確認済
http://gborg.postgresql.org/project/hierpg/projdisplay.php

あとは, contribのtablefuncに入ってるconnectby関数でも代用利きますよね
(SRF用いた関数レベルの実装で実用的かというと?ですけど..

部署の階層数が一定以下に決まっているのであれば, self-joinでやっても
よいのでは.


+-------------------------------------------------------------------+
Makoto Yui <yuin ＠ bb.din.or.jp>
Key fingerprint = 6462 E285 97D8 1323 40C4  F9E5 EB0F 9DE6 1713 219E
+-------------------------------------------------------------------+


From m_teracchi ＠ yahoo.co.jp  Sun May 11 02:45:32 2003
From: m_teracchi ＠ yahoo.co.jp (M Tera)
Date: Sun, 11 May 2003 02:45:32 +0900
Subject: [pgsql-jp: 29844] Windows2000 + Cygwin + PostgreSQL の組み合わせ
Message-ID: <20030511020309.FCD8.M_TERACCHI@yahoo.co.jp>

寺口と申します．
はじめて PostgreSQL のメーリングリストに投稿させていただきます．

現在，
「Windowsユーザのための PostgreSQL 導入活用ガイド」
および
Something PostgreSQL (http://www.nonsensecorner.com/pgsql/)
に基づきまして，下記環境で PostgreSQL を動作させようと試みております．
<環境>
Windows 2000
Cygwin 1.3.12
PostgreSQL 7.2.2

導入活用ガイドに付属の CD-ROM を用いて，次の手順でインストールを行いました．
(1) cygwin 1.3.12 をインストール
(2) cygipc-1.10.1-patched-bin.tar.bz2 を解凍してインストール
$ bzip2 -d -c cygipc-1.10.1-patched-bin.tar.bz2 | tar xvf - -C /usr/local
(3) postgresql7.2.2-cygwin-mb.tar.bz2 を解凍してインストール
$ bzip2 -d -c postgresql7.2.2-cygwin-mb.tar.bz2 | tar xvf - -C /usr/local
(4) 2つの環境変数を設定
PGDATA, PGLIB

この時点で

$ uname -a
CYGWIN_NT-5.0 TERA-THINKPAD 1.3.12(0.54/3/2) 2002-07-06 02:16 i686 unknown
$ psql -V
psql (PostgreSQL) 7.2.2
contains support for: readline, history, multibyte
$ env | grep PG
PGDATA=/mnt/e/Home/web/data
PGLIB=/usr/local/pgsql/lib

となっております．
続いて，ipc-daemon の起動，initdb, postmaster の起動を行いました．

$ ipc-daemon &
[1] 1796
$ initdb -E EUC_JP
The files belonging to this database system will be owned by user "root".
This user must also own the server process.

Fixing permissions on existing directory /mnt/e/Home/web/data... ok
creating directory /mnt/e/Home/web/data/base... ok
creating directory /mnt/e/Home/web/data/global... ok
creating directory /mnt/e/Home/web/data/pg_xlog... ok
creating directory /mnt/e/Home/web/data/pg_clog... ok
creating template1 database in /mnt/e/Home/web/data/base/1... ok
creating configuration files... ok
initializing pg_shadow... ok
enabling unlimited row size for system tables... ok
creating system views... ok
loading pg_description... ok
vacuuming database template1... ok
copying template1 to template0... ok

Success. You can now start the database server using:

    /usr/local/pgsql/bin/postmaster -D /mnt/e/Home/web/data
or
    /usr/local/pgsql/bin/pg_ctl -D /mnt/e/Home/web/data -l logfile start
$ postmaster -i &
[2] 1832
DEBUG:  database system was shut down at 2003-05-11 02:27:15 JST
DEBUG:  checkpoint record is at 0/113640
DEBUG:  redo record is at 0/113640; undo record is at 0/0; shutdown TRUE
DEBUG:  next transaction id: 89; next oid: 16556
DEBUG:  database system is ready

この時点では

$ ps
      PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
      328       1     328        328  con  500 01:58:01 /usr/bin/bash
     1796     328    1796        872  con  500 02:23:51 /usr/local/bin/ipc-daemon
     1832     328    1832       1944  con  500 02:27:59 /usr/local/pgsql/bin/postgres
     1952    1832    1832       1952  con  500 02:28:03 /usr/local/pgsql/bin/postgres
     1928    1952    1832       1928  con  500 02:28:03 /usr/local/pgsql/bin/postgres
     1940     328    1940        352  con  500 02:39:06 /usr/bin/ps
$ ipcs
---------- Shared Memory Segments --------
     shmid     key       bytes     nattch    status
_shm 0         5432001   1441792   1

---------- Semaphore Arrays --------
     semid     nsems     key
_sem 1792      17        5432001    currents: 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  537
_sem 1793      17        5432002    currents: 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  537
_sem 1794      17        5432003    currents: 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  537

---------- Message Queues --------
     msqid     used-bytes  messages

となっており，正しく動作しているように思えます．
しかしながら，psql を実行すると，次のようなエラーが生じて終了します．

$ psql template1
DEBUG:  pq_recvbuf: recv() failed: Socket operation on non-socket
DEBUG:  incomplete startup packet
psql: server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

ちなみに，環境変数に PGHOST 127.0.0.1 を追加し，postgresql.conf を修正して
tcpip_socket = true
port = 5432
としても同様のエラーが生じました．
また，本メーリングリストのアーカイブも調べたのですが，解決法を見出せずにおります．

本問題を解決するための方法等をご教授いただけますようお願い申し上げます．

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!  http://bb.yahoo.co.jp/



From yutaka ＠ hi-net.zaq.ne.jp  Sun May 11 11:46:14 2003
From: yutaka ＠ hi-net.zaq.ne.jp (Yutaka tanida)
Date: Sun, 11 May 2003 11:46:14 +0900
Subject: [pgsql-jp: 29845] Re: Windows2000 + Cygwin + PostgreSQL の組み合わせ
In-Reply-To: <20030511020309.FCD8.M_TERACCHI@yahoo.co.jp>
References: <20030511020309.FCD8.M_TERACCHI@yahoo.co.jp>
Message-ID: <20030511113544.6A29.YUTAKA@hi-net.zaq.ne.jp>

谷田です。

On Sun, 11 May 2003 02:45:32 +0900
M Tera <m_teracchi ＠ yahoo.co.jp> wrote:

> <環境>
> Windows 2000
> Cygwin 1.3.12
> PostgreSQL 7.2.2
(snip)
> となっており，正しく動作しているように思えます．

ここまでは正しいように思います。

> しかしながら，psql を実行すると，次のようなエラーが生じて終了します．
> 
> $ psql template1
> DEBUG:  pq_recvbuf: recv() failed: Socket operation on non-socket
> DEBUG:  incomplete startup packet
> psql: server closed the connection unexpectedly
>         This probably means the server terminated abnormally
>         before or while processing the request.
> 
> ちなみに，環境変数に PGHOST 127.0.0.1 を追加し，postgresql.conf を修正して
> tcpip_socket = true
> port = 5432
> としても同様のエラーが生じました．
> また，本メーリングリストのアーカイブも調べたのですが，解決法を見出せずにおります．

私も初めて聞く問題なのですが、一度Cygwinの最新版をインストールしてみては
如何でしょうか？

# 何か2000側の問題のような気がします。

---
Yutaka tanida<yutaka ＠ hi-net.zaq.ne.jp>
謎のWebsite http://www.nonsensecorner.com/



From mashiki ＠ yanah.com  Mon May 12 12:31:53 2003
From: mashiki ＠ yanah.com (Mashiki)
Date: Mon, 12 May 2003 12:31:53 +0900
Subject: [pgsql-jp: 29846] Re: 日付範囲内の日付を全て取得したいです
In-Reply-To: <20030509225739.E95D.SAIMI@oliver.co.jp>
References: <20030509225739.E95D.SAIMI@oliver.co.jp>
Message-ID: <13C31837082CF3mashiki@yanah.com>

　Mashikiです。

斎見さんのアイデアにちょっと触発されてしまいました。
7.3以降であれば

/* 連続した数字を行として返す関数 */
create or replace function enumerate(int4, int4)
   returns setof record as '
DECLARE
   rec record;
   cnt  int4;
BEGIN
   FOR cnt in $1..$2 LOOP
      select cnt into rec;
      return next rec;
   END LOOP;
   RETURN;
END;
' language 'plpgsql';

と、関数を定義しておき、

select '2003/01/01'::date + num
   from enumerate(0, 130-1) as enum(num int4);

とか

select '2003/01/01'::date + num from enumerate(0, 
   ('2003/5/10'::date-'2003/01/01'::date)::int4) as enum(num int4);

と検索することもできますね。


From yoichi_takano ＠ ha.daifuku.co.jp  Mon May 12 13:59:06 2003
From: yoichi_takano ＠ ha.daifuku.co.jp (yoichi_takano ＠ ha.daifuku.co.jp)
Date: Mon, 12 May 2003 13:59:06 +0900
Subject: [pgsql-jp: 29847] ファイルの肥大化
Message-ID: <49256D24.001B5CB6.00@smtpmta-osk.ha.daifuku.co.jp>



お世話になります。高野と申します。

Redhat8.0　PostgreSQL7.1.3で運用しております。

pgdata以下に大きなファイルができて、消えずに困っております。

bash-2.05$ ls -l /usr/local/pgsql/data/base/26228/16948*
-rw-------   1 postgres other    1073741824  8月  5  2002 16948
-rw-------   1 postgres other    1073741824  9月  9  2002 16948.1
-rw-------   1 postgres other    1073741824  9月 30  2002 16948.2
-rw-------   1 postgres other    1073741824 11月  5  2002 16948.3
-rw-------   1 postgres other    1073741824 11月 20 10:10 16948.4
-rw-------   1 postgres other    1073741824  1月 18 15:46 16948.5
-rw-------   1 postgres other    1073741824  3月 11 11:23 16948.6
-rw-------   1 postgres other    1073741824  3月 28 10:27 16948.7
-rw-------   1 postgres other    553181184  5月 12 13:24 16948.8
bash-2.05$

そこで以下のようにしてみるとラージオブジェクトで管理しているファイル
が大きくなっていのものと予想しましたが、実際ラージオブジェクトで管
理しているデータの合計は77965334 (byte)しかありません。

=# select * from pg_class where relfilenode='16948';
    relname     | reltype | relowner | relam | relfilenode | relpages | reltuple
s | reltoastrelid | reltoastidxid | relhasindex | relisshared | relkind | relnat
ts | relchecks | reltriggers | relukeys | relfkeys | relrefs | relhaspkey | relh
asrules | relhassubclass | relacl
----------------+---------+----------+-------+-------------+-
--+---------------+---------------+-------------+------------
---+-----------+-------------+----------+----------+---------
--------+----------------+--------
 pg_largeobject |   16949 |     1002 |     0 |       16948 |  1105669 |   335012
8 |             0 |             0 | t           | f           | r       |
 3 |         0 |           0 |        0 |        0 |       0 | f          | f
        | f              |
(1 row)


hoge=# \d pg_largeobject
     Table "pg_largeobject"
 Attribute |  Type   | Modifier
-----------+---------+----------
 loid     　　| oid     |
 pageno    | integer |
 data      　| bytea   |
Index: pg_largeobject_loid_pn_index

hoge=#

hoge=# select sum(file_size) from file_lobj;
   sum
----------
 77965334
(1 row)


念のため、MLにて井上様が以前ご指摘されて方法も行いましたが効果
はありませんでした。

http://www.sra.co.jp/people/t-ishii/PostgreSQL/old/mhonarc/pgsql-jp/2002Apr/msg00220.html
> 井上です。
> システムテーブルやインデクスを消去するとPostgresが
> 動かなくなってしまいます。pg_attributeのインデクス
> が膨れ上がっているようなのでインデクスを再編成して
> 圧縮する必要があります。
> 以下の手順でやってみてください。
> 1) postmasterを停止する。
> 2) standaloneのpostgresを起動する。
>  postgres -P -O データベース名
> 3) pg_attributeのインデクスを再編成する
>  reindex table pg_attribute force;
> 4) standaloneのpostgresを終了する(Ctrl-d)
> 5) postmasterを再起動する。

どなかたこの件についてご存知の方おられないでしょうか？

お手数ですが宜しくお願いします。






From saimi ＠ oliver.co.jp  Mon May 12 15:39:59 2003
From: saimi ＠ oliver.co.jp (斎見 浩平)
Date: Mon, 12 May 2003 15:39:59 +0900
Subject: [pgsql-jp: 29848] Re: ファイルの肥大化
In-Reply-To: <49256D24.001B5CB6.00@smtpmta-osk.ha.daifuku.co.jp>
References: <49256D24.001B5CB6.00@smtpmta-osk.ha.daifuku.co.jp>
Message-ID: <20030512153616.BA1F.SAIMI@oliver.co.jp>

> pgdata以下に大きなファイルができて、消えずに困っております。

1. pg_dumpでフルダンプ。
2. postmaster停止。
3. /usr/local/pgsql/dataをリネーム。
4. initdb.
5. postmaster再開。
6. pg_restoreでフルレストア。

をやってみては？

-- 
斎見 浩平 <saimi ＠ oliver.co.jp>




From yoichi_takano ＠ ha.daifuku.co.jp  Mon May 12 16:44:18 2003
From: yoichi_takano ＠ ha.daifuku.co.jp (yoichi_takano ＠ ha.daifuku.co.jp)
Date: Mon, 12 May 2003 16:44:18 +0900
Subject: [pgsql-jp: 29849] Re: ファイルの肥大化
Message-ID: <49256D24.002A7C4D.00@smtpmta-osk.ha.daifuku.co.jp>


お世話になります。高野と申します。


斎見様　データベースをバックアップし、レストアというご指摘ありが
ごとうございます。

ラージオブジェクトも含むので以下の方法でバックアップをとると物凄く
大きなバックアップファイルになります。

pg_dump -Ft -b db > db.tar

-rw-r--r--   1 postgres other    2212470784  5月 12 16:22 db.tar

ディスクが100％になってしまいこれ以上作業をすることができなかった
のですが、もしディスクに余裕がありできたとしましても、その後レストア
した場合には、サイズは大きいままに思えます。


参考までにこの方法↓ですと、97941byteです。
pg_dump > db.bkup
-rw-r--r--   1 postgres other      97941  5月 12 16:35 db.bkup


また、何か情報など足りないということでしたらご指摘下さい。

以上宜しくお願い致します。

>
> 1. pg_dumpでフルダンプ。
> 2. postmaster停止。
> 3. /usr/local/pgsql/dataをリネーム。
> 4. initdb.
> 5. postmaster再開。
> 6. pg_restoreでフルレストア。
>





From saimi ＠ oliver.co.jp  Mon May 12 19:08:17 2003
From: saimi ＠ oliver.co.jp (斎見 浩平)
Date: Mon, 12 May 2003 19:08:17 +0900
Subject: [pgsql-jp: 29850] Re: ファイルの肥大化
In-Reply-To: <49256D24.002A7C4D.00@smtpmta-osk.ha.daifuku.co.jp>
References: <49256D24.002A7C4D.00@smtpmta-osk.ha.daifuku.co.jp>
Message-ID: <20030512190252.6F66.SAIMI@oliver.co.jp>

ラージオブジェクトの実装がどうなってるかよく分かりませんが、要するに
無駄なデータがいっぱいあるのですね。

たとえば

SELECT f.loid FROM file_lobj f
LEFT OUTER JOIN pg_largeobject p
 ON f.loid = p.loid
WHERE p.loid IS NULL;

の出力はどうなりますか？
行が返るようならば、そのoidのラージオブジェクトを削除しましょう。
その後に、pg_largeobjectをvacuumしてみたらどうなりますか？

-- 
斎見 浩平 <saimi ＠ oliver.co.jp>




From saimi ＠ oliver.co.jp  Mon May 12 19:11:56 2003
From: saimi ＠ oliver.co.jp (斎見 浩平)
Date: Mon, 12 May 2003 19:11:56 +0900
Subject: [pgsql-jp: 29851] Re: ファイルの肥大化
In-Reply-To: <49256D24.002A7C4D.00@smtpmta-osk.ha.daifuku.co.jp>
References: <49256D24.002A7C4D.00@smtpmta-osk.ha.daifuku.co.jp>
Message-ID: <20030512190928.6F69.SAIMI@oliver.co.jp>

失礼、SQLを書き直します。

>SELECT f.loid FROM file_lobj f
>LEFT OUTER JOIN pg_largeobject p
> ON f.loid = p.loid
>WHERE p.loid IS NULL;

SELECT p.loid FROM pg_largeobject
LEFT OUTER JOIN file_lobj f
 ON p.loid = f.loid
WHERE f.loid IS NULL;

外部結合が逆でした。
要するに管理されてないoidを検索するという意味です。

-- 
斎見 浩平 <saimi ＠ oliver.co.jp>




From yutaka ＠ hi-net.zaq.ne.jp  Mon May 12 19:13:34 2003
From: yutaka ＠ hi-net.zaq.ne.jp (Yutaka tanida)
Date: Mon, 12 May 2003 19:13:34 +0900
Subject: [pgsql-jp: 29852] Re: ファイルの肥大化
In-Reply-To: <49256D24.001B5CB6.00@smtpmta-osk.ha.daifuku.co.jp>
References: <49256D24.001B5CB6.00@smtpmta-osk.ha.daifuku.co.jp>
Message-ID: <20030512191124.DB5C.YUTAKA@hi-net.zaq.ne.jp>

谷田です。

On Mon, 12 May 2003 13:59:06 +0900
yoichi_takano ＠ ha.daifuku.co.jp wrote:

(snip)
> そこで以下のようにしてみるとラージオブジェクトで管理しているファイル
> が大きくなっていのものと予想しましたが、実際ラージオブジェクトで管
> 理しているデータの合計は77965334 (byte)しかありません。
(snip)
> hoge=# select sum(file_size) from file_lobj;
>    sum
> ----------
>  77965334
> (1 row)

余分なラージオブジェクトを削除するのであれば、contrib/vacuumloを使ってみ
ては如何でしょうか？

これはPostgreSQLのソースコードに付属しています。

-- 
Yutaka tanida <yutaka ＠ nonsensecorner.com>
http://www.nonsensecorner.com/



From sugita ＠ sra.co.jp  Mon May 12 19:53:56 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Mon, 12 May 2003 19:53:56 +0900 (JST)
Subject: [pgsql-jp: 29853] Re: ファイルの肥大化
In-Reply-To: <49256D24.001B5CB6.00@smtpmta-osk.ha.daifuku.co.jp>
References: <49256D24.001B5CB6.00@smtpmta-osk.ha.daifuku.co.jp>
Message-ID: <20030512.195356.88489818.sugita@sra.co.jp>

  杉田です。

From: yoichi_takano ＠ ha.daifuku.co.jp
Subject: [pgsql-jp: 29847] ファイルの肥大化
Date: Mon, 12 May 2003 13:59:06 +0900

;;; お世話になります。高野と申します。
;;; 
;;; Redhat8.0　PostgreSQL7.1.3で運用しております。
;;; 
;;; pgdata以下に大きなファイルができて、消えずに困っております。
;;; 
;;; bash-2.05$ ls -l /usr/local/pgsql/data/base/26228/16948*
;;; -rw-------   1 postgres other    1073741824  8月  5  2002 16948
;;; -rw-------   1 postgres other    1073741824  9月  9  2002 16948.1
;;; -rw-------   1 postgres other    1073741824  9月 30  2002 16948.2
;;; -rw-------   1 postgres other    1073741824 11月  5  2002 16948.3
;;; -rw-------   1 postgres other    1073741824 11月 20 10:10 16948.4
;;; -rw-------   1 postgres other    1073741824  1月 18 15:46 16948.5
;;; -rw-------   1 postgres other    1073741824  3月 11 11:23 16948.6
;;; -rw-------   1 postgres other    1073741824  3月 28 10:27 16948.7
;;; -rw-------   1 postgres other    553181184  5月 12 13:24 16948.8
;;; bash-2.05$
;;; 
;;; そこで以下のようにしてみるとラージオブジェクトで管理しているファイル
;;; が大きくなっていのものと予想しましたが、実際ラージオブジェクトで管
;;; 理しているデータの合計は77965334 (byte)しかありません。
...
;;; hoge=# select sum(file_size) from file_lobj;
;;;    sum
;;; ----------
;;;  77965334
;;; (1 row)

  このようにしてアプリケーション側で管理しているデータのサイズが正しいとするな
らば、PostgreSQL 側の問題ではなく、アプリケーション側が、アプリケーション的に
不要になったラージオブジェクトの削除をしていないのではないでしょうか?


Kenji Sugita                                      



From noriko ＠ dino.co.jp  Mon May 12 20:12:51 2003
From: noriko ＠ dino.co.jp (Eidome Noriko)
Date: Mon, 12 May 2003 20:12:51 +0900
Subject: [pgsql-jp: 29854] Re: ファイルの肥大化
In-Reply-To: <49256D24.001B5CB6.00@smtpmta-osk.ha.daifuku.co.jp>
References: <49256D24.001B5CB6.00@smtpmta-osk.ha.daifuku.co.jp>
Message-ID: <20030512201251.3b53facc.noriko@dino.co.jp>

えいどめ ともうします。

昔、似たような状況におちいったことがあります。
30万件前後の insert / delete 1時間おきに繰り返していたら、
データが膨大な量になっていました。
# ラージオブジェクト は使っていませんが

その時は
http://ml.postgresql.jp/pipermail/pgsql-jp/2002-May/001210.html
から始まるスレッドを参考にしました。
7.2.1 の話なので、状況が異なるかもしれませんが…

そのときやったことは、
1) とりあえず、VACUME FULL を実行
2) MAX_FSM_PAGES というのを大きくした
   /var/lib/poistgresql/data/postmaster.opts
  に 起動時オプションを追加する。
  ex. /usr/lib/postgresql/bin/postmaster -c MAX_FSM_PAGES=2000000
3) VACUUM しまくる ( 1時間に1回 )

はずしてたらごめんなさい。

--
Eidome Noriko < noriko ＠ dino.co.jp >



From koyama ＠ hoge.org  Mon May 12 21:18:59 2003
From: koyama ＠ hoge.org (KOYAMA Tetsuji)
Date: Mon, 12 May 2003 21:18:59 +0900
Subject: [pgsql-jp: 29856] Re: About UTF-8 encoding
In-Reply-To: <20030512201514.2da1edb3.yuin@bb.din.or.jp>
References: <20030512201514.2da1edb3.yuin@bb.din.or.jp>
Message-ID: <87bry8we6k.wl@poseidon.hoge.org>

  小山です。

At Mon, 12 May 2003 20:15:14 +0900,
Makoto,Yui <yuin ＠ bb.din.or.jp> wrote:
> そこで, UTF-8でのbit_lengthを図ると...
> select bit_length(convert('127','UTF-8'))/8 as byte
> --
> byte
> 3

  これでは '127' という文字列を UTF-8 に変換して(当然そのまま)、そのビッ
ト長を計っていませんか? ASCIIコード 127 の文字に対して同様の処理をした
いのなら

select bit_length(convert(chr(127),'UTF-8'))/8 as byte

とやらないと。

-- 
	小山 哲志＠ビート・クラフト
	koyama ＠ beatcraft.com
	koyama ＠ hoge.org


From yuin ＠ bb.din.or.jp  Mon May 12 21:25:41 2003
From: yuin ＠ bb.din.or.jp (Makoto,Yui)
Date: Mon, 12 May 2003 21:25:41 +0900
Subject: [pgsql-jp: 29857] Re: About UTF-8 encoding
In-Reply-To: <20030512201514.2da1edb3.yuin@bb.din.or.jp>
References: <20030512201514.2da1edb3.yuin@bb.din.or.jp>
Message-ID: <20030512212541.249df350.yuin@bb.din.or.jp>

油井です.

小山さん@ビート・クラフトから直接解法のメールを頂きました.
#解決したことを添えて, MLにも流します.

>   これでは '127' という文字列を UTF-8 に変換して(当然そのまま)、そのビッ
> ト長を計っていませんか? ASCIIコード 127 の文字に対して同様の処理をした
> いのなら
> 
> select bit_length(convert(chr(127),'UTF-8'))/8 as byte

その通りですね.
これから確認してみます. 有り難うございました.


+-------------------------------------------------------------------+
Makoto Yui <yuin ＠ bb.din.or.jp>
Key fingerprint = 6462 E285 97D8 1323 40C4  F9E5 EB0F 9DE6 1713 219E
+-------------------------------------------------------------------+


From yuin ＠ bb.din.or.jp  Mon May 12 21:28:08 2003
From: yuin ＠ bb.din.or.jp (Makoto,Yui)
Date: Mon, 12 May 2003 21:28:08 +0900
Subject: [pgsql-jp: 29858] Re: About UTF-8 encoding
In-Reply-To: <20030512201514.2da1edb3.yuin@bb.din.or.jp>
References: <20030512201514.2da1edb3.yuin@bb.din.or.jp>
Message-ID: <20030512212808.7fbad2d9.yuin@bb.din.or.jp>

油井です.

っと, 度々すいません.
MLにちゃんと来てましたね. 環境変えていたものでメールの
フィルタリングがちゃんとできてませんでした.
#余計なお世話をしてしまったということで..

+-------------------------------------------------------------------+
Makoto Yui <yuin ＠ bb.din.or.jp>
Key fingerprint = 6462 E285 97D8 1323 40C4  F9E5 EB0F 9DE6 1713 219E
+-------------------------------------------------------------------+


From senjyu ＠ f2.dion.ne.jp  Mon May 12 22:14:36 2003
From: senjyu ＠ f2.dion.ne.jp (Ihara)
Date: Mon, 12 May 2003 22:14:36 +0900
Subject: [pgsql-jp: 29859] Re: トランザクションエラーについて。
References: <Law15-F19aatao8KK8Z000154fa@hotmail.com> <003b01c30a0e$93cde4f0$1e9316ac@sys010>
Message-ID: <3EBF9E3C.605@f2.dion.ne.jp>

 Ihara と申します。
その後、この話題が完結するのを期待していたのですが、
完結していないようなので、ちょっとよこはいりさせて頂きます。

私も同様の現象がたまに発生します。
それは、Apache+php+PostgreSQLでプログラムを作成しているのですが、
BEGINでトランザクションの開始 をさせたあと、COMMITまでの間に、
phpで作っているプログラムのコーディングミスがあって、PostgreSQLへのSQL文が
エラーとなった場合です。エラーとなった場合には、ROLLBACKさせる処理もいれ
ています。
こんな感じです。
$sql = "INSERT ・・・・・";　←　この文にミスがあり、
$ret = pg_exec( $id, $sql);　←　この命令でエラーになり、
if( ! $ret ) {
$sql = "ROLLBACK";　←　ROLLBACKを行なう。
pg_exec( $id, $sql);
exit();
}
このエラーとなった部分のPHPのPGを修正して、ブラウザの再読みこみボタンや
戻るボタンなどを使いながら、その部分をデバッグしていると、最初はこのメッ
セージのエラーは発生しないのですが、
何回目かに同じく、

transaction is aborted, queries ignored until end of transaction block

というメッセージが出力されます。

しかも、そのメッセージが出力された後は、この部分以外のところのSelect文で
も出力されるようになり、
で、仕方なくPostgreSQLを再起動させて復活させています。

結果的には、コーディングミスがなくなると、このエラーが発生しにくくなる
（といいますか今のところ発生していません。）ので、問題ないと言えば問題な
いのですが、開発が完了し、オンライン運用になった際に、万一、同様の現象が
発生したときに、再起動させないで復活させたいのですが、この状態を回避させ
る方法がわかりません。

ということで、
１．なぜ、何回目かにこのメッセージが出力されてしまうのか？
２．このエラーが発生した場合の復活方法
がわかりません。

以上、よろしくお願いします。




From hosoi ＠ ryo.com  Tue May 13 04:10:27 2003
From: hosoi ＠ ryo.com (Ryosuke Hosoi)
Date: Mon, 12 May 2003 12:10:27 -0700 (PDT)
Subject: [pgsql-jp: 29860] Re: トランザクションエラーについて。
In-Reply-To: <3EBF9E3C.605@f2.dion.ne.jp>
References: <Law15-F19aatao8KK8Z000154fa@hotmail.com>
	<003b01c30a0e$93cde4f0$1e9316ac@sys010>
	<3EBF9E3C.605@f2.dion.ne.jp>
Message-ID: <20030512.121027.730555631.hosoi@ryo.com>

ほそいです

From: Ihara <senjyu ＠ f2.dion.ne.jp>
Subject: [pgsql-jp: 29859] Re: トランザクションエラーについて。
Date: Mon, 12 May 2003 22:14:36 +0900
Message-ID: <3EBF9E3C.605 ＠ f2.dion.ne.jp>

> １．なぜ、何回目かにこのメッセージが出力されてしまうのか？

pConnectを使っていて、
前回のbegin->commit or rollback
までの間にphpがエラーやブラウザからのセッション切れで停止
していたため、
何回目かにその続きのpostgresセッションに繋がってるんじゃないですか？

> ２．このエラーが発生した場合の復活方法

1. apacheの再起動 or postgresの再起動
2. 上記のような状態にならないようなコーディング
 -a. 簡単な方法としてはトランザクションを使用する部分ではpConnectしない
などなど。。。

-- 
 Ryosuke Hosoi / 細井 良祐
 mailto:hosoi ＠ ryo.com http://www.ryo.com/
 PGP Public Key http://www.ryo.com/ryo/hosoi.ryo.com.asc
 fingerprint = 4F39 61B0 2034 3A5C DFE8  FBCB 7B99 90CF EBE1 A3F3


From m_teracchi ＠ yahoo.co.jp  Tue May 13 12:43:34 2003
From: m_teracchi ＠ yahoo.co.jp (M Tera)
Date: Tue, 13 May 2003 12:43:34 +0900 (JST)
Subject: [pgsql-jp: 29861] Re: Windows2000 + Cygwin + PostgreSQL  の組み合わせ
In-Reply-To: <20030511113544.6A29.YUTAKA@hi-net.zaq.ne.jp>
Message-ID: <20030513034334.21775.qmail@web601.mail.yahoo.co.jp>

寺口です。

 --- Yutaka tanida <yutaka ＠ hi-net.zaq.ne.jp> からのメッセージ：
> 私も初めて聞く問題なのですが、一度Cygwinの最新版をインストールしてみて
は
> 如何でしょうか？
> 
> # 何か2000側の問題のような気がします。

谷田様の提案に従いまして、Cygwin最新版をインストールしてみました。

$ uname -a
CYGWIN_NT-5.0 TERA-HOME 1.3.22(0.78/3/2) 2003-03-18 09:20 i686 unknown
unknown Cygwin

ipc-daemon, postgreSQL は谷田様の web site (Somethig PostgreSQL) にありま
す
cygipc-1.13.2-patched-bin.tar.bz2
postgresql-7.3.1-cygwin.tar.bz2
をダウンロードさせていただき、インストールしました。

再度 ipc-daemon の起動、データベースの初期化、postmaster の起動を行ったと
ころ

$ ipc-daemon &
[1] 1400

$ initdb -E EUC_JP --no-locale
The files belonging to this database system will be owned by user "root".
This user must also own the server process.

The database cluster will be initialized with locale C.

creating directory /usr/local/pgsql/data... ok
creating directory /usr/local/pgsql/data/base... ok
creating directory /usr/local/pgsql/data/global... ok
creating directory /usr/local/pgsql/data/pg_xlog... ok
creating directory /usr/local/pgsql/data/pg_clog... ok
creating template1 database in /usr/local/pgsql/data/base/1... ok
creating configuration files... ok
initializing pg_shadow... ok
enabling unlimited row size for system tables... ok
initializing pg_depend... ok
creating system views... ok
loading pg_description... ok
creating conversions... ok
setting privileges on built-in objects... ok
vacuuming database template1... ok
copying template1 to template0... ok

Success. You can now start the database server using:

    /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data
or
    /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start

$ postmaster -i &
[2] 300
$ LOG:  database system was shut down at 2003-05-13 12:39:20 JST
LOG:  checkpoint record is at 0/83B1A8
LOG:  PGSTATBUFF: recvfrom() failed: Socket operation on non-socket
LOG:  redo record is at 0/83B1A8; undo record is at 0/0; shutdown TRUE
LOG:  next transaction id: 480; next oid: 16976
LOG:  statistics collector process (pid 1720) exited with exit code 1
LOG:  database system is ready
LOG:  PGSTATBUFF: recvfrom() failed: Socket operation on non-socket
LOG:  statistics collector process (pid 1696) exited with exit code 1
LOG:  PGSTATBUFF: recvfrom() failed: Socket operation on non-socket
LOG:  statistics collector process (pid 1780) exited with exit code 1
LOG:  PGSTATBUFF: recvfrom() failed: Socket operation on non-socket
LOG:  statistics collector process (pid 1848) exited with exit code 1
LOG:  PGSTATBUFF: recvfrom() failed: Socket operation on non-socket
LOG:  statistics collector process (pid 1756) exited with exit code 1
LOG:  PGSTATBUFF: recvfrom() failed: Socket operation on non-socket
LOG:  statistics collector process (pid 1616) exited with exit code 1
..... (以下、プロセスを止めるまで続く)

となり、状況がさらに悪化したように思います。
何か解決策はございますでしょうか？
申し訳ありませんが、よろしくお願いいたします。


__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/



From yutaka ＠ hi-net.zaq.ne.jp  Tue May 13 13:18:50 2003
From: yutaka ＠ hi-net.zaq.ne.jp (Yutaka tanida)
Date: Tue, 13 May 2003 13:18:50 +0900
Subject: [pgsql-jp: 29862] Re: Windows2000 + Cygwin + PostgreSQL の組み合わせ
In-Reply-To: <20030513034334.21775.qmail@web601.mail.yahoo.co.jp>
References: <20030511113544.6A29.YUTAKA@hi-net.zaq.ne.jp> <20030513034334.21775.qmail@web601.mail.yahoo.co.jp>
Message-ID: <20030513130436.7B2A.YUTAKA@hi-net.zaq.ne.jp>

谷田です。

On Tue, 13 May 2003 12:43:34 +0900 (JST)
M Tera <m_teracchi ＠ yahoo.co.jp> wrote:

> > 私も初めて聞く問題なのですが、一度Cygwinの最新版をインストールしてみて
> は
> > 如何でしょうか？
(snip)
> 谷田様の提案に従いまして、Cygwin最新版をインストールしてみました。
> 
> $ uname -a
> CYGWIN_NT-5.0 TERA-HOME 1.3.22(0.78/3/2) 2003-03-18 09:20 i686 unknown
> unknown Cygwin
> 
> ipc-daemon, postgreSQL は谷田様の web site (Somethig PostgreSQL) にありま
> す
> cygipc-1.13.2-patched-bin.tar.bz2
> postgresql-7.3.1-cygwin.tar.bz2
> をダウンロードさせていただき、インストールしました。
(snip)
> となり、状況がさらに悪化したように思います。
> 何か解決策はございますでしょうか？

解決の糸口になるかどうかは分かりませんが、プロンプトから'cygcheck -svr'
したときの出力を見せて頂けますか？

-- 
Yutaka tanida <yutaka ＠ nonsensecorner.com>
http://www.nonsensecorner.com/



From ogino ＠ sic.co.jp  Tue May 13 18:15:19 2003
From: ogino ＠ sic.co.jp (Ogino)
Date: Tue, 13 May 2003 18:15:19 +0900
Subject: [pgsql-jp: 29863] Postgresでの日本語検索
Message-ID: <200305130912.SAA15812@asagao.sic.co.jp>

はじめまして。PostgreSQLメーリングリスト
に入ったばかりの、荻野といいます。
どうぞよろしくお願いします。

今、Postgresを使っていて、奇妙な問題に直面しており、
お力を借りたく投稿しています。

テーブルのカラムに、日本語の読み仮名が入っています。

(例 : Testテーブル)
name     kana
----------------
荻野     おぎの
山田　　 やまだ
大森　　 おおもり
岩瀬　　　いわせ


これを、カナの先頭の文字ごとにグループ化して
取り出したいと思っています。
例えば、先頭が「か」からはじまる物なら

select * from Test where substr(kana ,1,1) >='か'
   and substr(kana,1,1) < 'き'

というようなSQLを発行しています。
しかし、このとき、上記のSQLでは期待した通りの
結果を得ることができません。

**実際の結果****'

select * from KEYWORD  where substr(kana,1,1) >= 'み'
 and substr(kana,1,1) < 'む'   order by kana ASC;

 key_id | keyword  |      kana
--------+----------+----------------
     21 | 足の痛み | あしのいたみ
     31 | 飲料水   | いんりょうすい
     22 | 塩分     | えんぶん
     24 | 海外     | かいがい
     27 | 呼吸     | こきゅう
     20 | 食道炎   | しょくどうえん
      2 | 症状     | しょうじょう
     23 | 心臓     | しんぞう
     12 | 咳       | せき
      8 | 体脂肪率 | たいしぼうりつ
     28 | 負荷試験 | ふかしけん
     13 | 保険     | ほけん

ここでは、「み」からはじまるカラムがほしいのに、
わけのわからないものが選択されてしまいます。
なにか、ご存知の方がいましたら、ご教授ねがえないでしょうか？

Postgresは、7.3.2を使っています。
RedHatLinux8.0上で動作しております。

お手数かと思いますが、よろしくお願いします。








From kmatsuda ＠ lisonal.com  Tue May 13 18:31:07 2003
From: kmatsuda ＠ lisonal.com (松田勝己)
Date: Tue, 13 May 2003 18:31:07 +0900
Subject: [pgsql-jp: 29864] Re: Postgresでの日本語検索
In-Reply-To: <200305130912.SAA15812@asagao.sic.co.jp>
References: <200305130912.SAA15812@asagao.sic.co.jp>
Message-ID: <200305130931.AA00705@kmatsuda.lisonal.com>

松田＠リソナルです

記載されているSQL文の妥当性については深追いしてませんが
正規表現を使った方が楽なんじゃないでしょうか？

select * from KEYWORD  where kana~'^か' order by kana ASC;

ってな感じです。

Ogino さんは書きました:
>
>**実際の結果****'
>
>select * from KEYWORD  where substr(kana,1,1) >= 'み'
> and substr(kana,1,1) < 'む'   order by kana ASC;
>
> key_id | keyword  |      kana
>--------+----------+----------------
>     21 | 足の痛み | あしのいたみ
>     31 | 飲料水   | いんりょうすい
>     22 | 塩分     | えんぶん
>     24 | 海外     | かいがい
>     27 | 呼吸     | こきゅう
>     20 | 食道炎   | しょくどうえん
>      2 | 症状     | しょうじょう
>     23 | 心臓     | しんぞう
>     12 | 咳       | せき
>      8 | 体脂肪率 | たいしぼうりつ
>     28 | 負荷試験 | ふかしけん
>     13 | 保険     | ほけん
>
>ここでは、「み」からはじまるカラムがほしいのに、
>わけのわからないものが選択されてしまいます。
>なにか、ご存知の方がいましたら、ご教授ねがえないでしょうか？

------------------------------
有限会社リソナル 松田 勝己
E-Mail:kmatsuda ＠ lisonal.com URL:http://www.lisonal.com/
TEL   :03-3643-4991 FAX:03-3643-4993
得盛サーバーハウジング
http://www.lisonal.com/index.php?%5B%5B%C6%C0%C0%B9%5D%5D


From sirius ＠ jp.fujitsu.com  Tue May 13 18:46:29 2003
From: sirius ＠ jp.fujitsu.com (Takao Kato)
Date: Tue, 13 May 2003 18:46:29 +0900
Subject: [pgsql-jp: 29865] Re: Postgresでの日本語検索
In-Reply-To: <200305130912.SAA15812@asagao.sic.co.jp>
References: <200305130912.SAA15812@asagao.sic.co.jp>
Message-ID: <u33cjjmb62.wl@lespaul.lantc.cs.fujitsu.co.jp>

加藤＠川崎です。

FAQだったりする気がする....

> はじめまして。PostgreSQLメーリングリスト
> に入ったばかりの、荻野といいます。

まずはアーカイブ検索を試されるのがよろしいかと思います。わりと最近も同
じ現象で苦しんでいる人がいたような記憶があります。
# と突き放せるなら楽なんだけれど ^^;

> select * from KEYWORD  where substr(kana,1,1) >= 'み'
>  and substr(kana,1,1) < 'む'   order by kana ASC;
> 
..snip..
>
> ここでは、「み」からはじまるカラムがほしいのに、
> わけのわからないものが選択されてしまいます。
> なにか、ご存知の方がいましたら、ご教授ねがえないでしょうか？


(7.3.2ですから) initdb 実行時に --no-locale 指定していない...に一票!!


ちなみに 7.1.2 で configure 時に no-locale と enable-multibyte を指定
した環境では、以下が正しく動作するのを確認しています。
# 『正規表現の方が』と突っ込みもはいっていますが、あえて substr 利用

-- 8< -- 8< -- 8< --
create temp table test(
  a text
);

-- は〜ほ ま〜も ら〜ろ を3文字づつ区切り
-- その3文字を並び替え
INSERT INTO test VALUES('はひふ');
INSERT INTO test VALUES('ひふは');
INSERT INTO test VALUES('ふはひ');
INSERT INTO test VALUES('へほま');
INSERT INTO test VALUES('ほまへ');
INSERT INTO test VALUES('まへほ');
INSERT INTO test VALUES('みむめ');
INSERT INTO test VALUES('むめみ');
INSERT INTO test VALUES('めみむ');
INSERT INTO test VALUES('もらり');
INSERT INTO test VALUES('らりも');
INSERT INTO test VALUES('りもら');
INSERT INTO test VALUES('るれろ');
INSERT INTO test VALUES('れろる');
INSERT INTO test VALUES('ろるれ');

select * from test where substr(a,1,1) >= 'み' and substr(a,1,1) < 'む';
-- 8< -- 8< -- 8< --

ではでは
----
加藤＠川崎
お便りは kato ＠ lantc.cs.fujitsu.co.jp まで


From yoichi_takano ＠ ha.daifuku.co.jp  Tue May 13 21:55:26 2003
From: yoichi_takano ＠ ha.daifuku.co.jp (yoichi_takano ＠ ha.daifuku.co.jp)
Date: Tue, 13 May 2003 21:55:26 +0900
Subject: [pgsql-jp: 29866] Re: ファイルの肥大化【解決】
Message-ID: <49256D25.0046F74E.00@smtpmta-osk.ha.daifuku.co.jp>


お世話になります。高野と申します。


斎見様、谷田様、えいどめ様、杉田様　メールありがとうございます。


結論からいうと、余分なラージオブジェクトを削除していないことが問題でした。

以下の通り、実際のラージオブジェクトは別の場所にあることを知りませんでした。
http://ml.postgresql.jp/pipermail/pgsql-jp/2002-April/000831.html

そのため私が作った　file_lob テーブルの中を削除すればラージオブジェクト
も削除されると思ってました。

hoge=# select count(*) from file_lobj;
 count
-------
    16
(1 row)
hoge=#

しかし、以下のようにすると沢山のデータがありました。
hoge=# select count(*) from pg_largeobject;
  count
---------
 3354046
(1 row)
hoge=# \q


ラージオブジェクトを削除するには\lo_unlinkを使えばできそうですが、
沢山あるので　谷田さんが紹介された　contrib/vacuumlo　で行い
無事に解決できました。

bash-2.05$ ./vacuumlo -v dex
Connected to db
Checking id in file_lobj
Removing lo 327003
Removing lo 637667
 ............
Removing lo 3218649
Removing lo 3344115
Removed 766 large objects from dex.
bash-2.05$
bash-2.05$

hoge=# vacuum;
VACUUM
hoge=#
hoge=# select count(*) from pg_largeobject;
 count
-------
 36565
(1 row)
hoge=#


皆様本当にありがとうございました。


#斎見様
p.loid　や　f.loid というのがよく分かりませんでした。

SELECT p.loid FROM pg_largeobject
LEFT OUTER JOIN file_lobj f
 ON p.loid = f.loid
WHERE f.loid IS NULL;







From m_teracchi ＠ yahoo.co.jp  Wed May 14 11:27:06 2003
From: m_teracchi ＠ yahoo.co.jp (M Tera)
Date: Wed, 14 May 2003 11:27:06 +0900
Subject: [pgsql-jp: 29867] Re: Windows2000 + Cygwin + PostgreSQL の組み合わせ
In-Reply-To: <20030513130436.7B2A.YUTAKA@hi-net.zaq.ne.jp>
References: <20030513034334.21775.qmail@web601.mail.yahoo.co.jp> <20030513130436.7B2A.YUTAKA@hi-net.zaq.ne.jp>
Message-ID: <20030514112058.F599.M_TERACCHI@yahoo.co.jp>

寺口です．

 --- Yutaka tanida <yutaka ＠ hi-net.zaq.ne.jp> からのメッセージ：
> 解決の糸口になるかどうかは分かりませんが、プロンプトから'cygcheck -svr'
> したときの出力を見せて頂けますか？

私のマシンで 'cygcheck -svr' を実行した結果を以下に示します．
お手数をおかけして申し訳ありませんが，よろしくお願いいたします．

--- ここから ---
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Wed May 14 00:08:24 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3

Path:   D:\Bin\Cygwin\usr\local\bin
        D:\Bin\Cygwin\bin
        D:\Bin\Cygwin\bin
        D:\Bin\Cygwin\usr\local\bin
        D:\Bin\Cygwin\bin
        D:\Bin\Cygwin\bin
        c:\WINNT\system32
        c:\WINNT
        c:\WINNT\System32\Wbem
        d:\Bin\Tex\pLaTeX\bin
        d:\Bin\Tex\dviout
        d:\Bin\Tex\gstools\gs7.00\bin
        .
        D:\Bin\Cygwin\bin
        D:\Bin\Cygwin\usr\local\pgsql\bin
        D:\Bin\Cygwin\usr\local\pgsql\lib

D:\Bin\Cygwin\bin\id.exe output (nontsec)
UID: 500(root)       GID: 544(Administrators)
所属グループ=513(none)      544(Administrators)
545(Users)

D:\Bin\Cygwin\bin\id.exe output (ntsec)
UID: 500(root)       GID: 544(Administrators)
所属グループ=513(none)      544(Administrators)
545(Users)

SysDir: C:\WINNT\System32
WinDir: C:\WINNT

CYGWIN = `binmode ntsec tty'
HOME = `e:\Home\tera'
MAKE_MODE = `unix'
PWD = `/cygdrive/e/Home/tera'
USER = `root'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\Administrator\Application Data'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `TERA-HOME'
COMSPEC = `C:\WINNT\system32\cmd.exe'
CVS_RSH = `/bin/ssh'
GS_LIB =
`D:\Bin\Tex\gstools\gs7.00\lib;D:\Bin\Tex\gstools\gs7.00\kanji;D:\Bin\Tex\gstools\fonts'
HOMEDRIVE = `C:'
HOMEPATH = `\'
HOSTNAME = `TERA-HOME'
LC_ALL = `ja_JP.SJIS'
LOGONSERVER = `\\TERA-HOME'
MANPATH = `:/usr/ssl/man:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/cygdrive/e/Home/tera'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PGDATA = `/usr/local/pgsql/data'
PGLIB = `/usr/local/pgsql/lib'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 0 Stepping 10, GenuineIntel'
PROCESSOR_LEVEL = `15'
PROCESSOR_REVISION = `000a'
PROGRAMFILES = `C:\Program Files'
PROMPT = `$P$G'
PS1 = `\[\033]0;\w\007
\033[32m\]\u@\h \[\033[33m\w\033[0m\]
$ '
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `d:\Temp'
TERM = `cygwin'
TEXMFCNF = `D:/Bin/Tex/pLaTeX/share/texmf/web2c'
TEXMFMAIN = `D:/Bin/Tex/pLaTeX/share/texmf'
TMP = `d:\Temp'
TMPDIR = `D:\Bin\Cygwin\tmp'
TZ = `JST-09'
USERDOMAIN = `TERA-HOME'
USERNAME = `root'
USERPROFILE = `C:\Documents and Settings\Administrator'
WINDIR = `C:\WINNT'
_ = `/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\S
tart Menu\Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x00000022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `D:\Bin\Cygwin'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `D:\Bin\Cygwin/bin'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `D:\Bin\Cygwin/lib'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

a:  fd           N/A    N/A
c:  hd  FAT32   6255Mb  68% CP    UN           SYSTEM
d:  hd  NTFS   11272Mb  95% CP CS UN PA FC     APPLICATION
e:  hd  NTFS   39715Mb  47% CP CS UN PA FC     DATA
f:  cd           N/A    N/A
q:  cd           N/A    N/A

D:\Bin\Cygwin      /          system  binmode
D:\Bin\Cygwin/bin  /usr/bin   system  binmode
D:\Bin\Cygwin/lib  /usr/lib   system  binmode
.                  /cygdrive  system  binmode,cygdrive

Found: D:\Bin\Cygwin\bin\awk.exe
Found: D:\Bin\Cygwin\bin\bash.exe
Found: D:\Bin\Cygwin\bin\cat.exe
Found: D:\Bin\Cygwin\bin\cp.exe
Found: D:\Bin\Cygwin\bin\cpp.exe
Found: D:\Bin\Cygwin\bin\find.exe
Found: D:\Bin\Cygwin\bin\gcc.exe
Found: D:\Bin\Cygwin\bin\gdb.exe
Found: D:\Bin\Cygwin\bin\grep.exe
Found: D:\Bin\Cygwin\bin\ld.exe
Found: D:\Bin\Cygwin\bin\ls.exe
Found: D:\Bin\Cygwin\bin\make.exe
Found: D:\Bin\Cygwin\bin\mv.exe
Found: D:\Bin\Cygwin\bin\rm.exe
Found: D:\Bin\Cygwin\bin\sed.exe
Found: D:\Bin\Cygwin\bin\sh.exe
Found: D:\Bin\Cygwin\bin\tar.exe

   58k 2002/05/07 D:\Bin\Cygwin\bin\cygbz2-1.dll - os=4.0 img=1.0 sys=4.0
                  "cygbz2-1.dll" v0.0 ts=2002/5/7 15:33
    6k 2002/06/24 D:\Bin\Cygwin\bin\cygcharset-1.dll - os=4.0 img=1.0
sys=4.0
                  "cygcharset-1.dll" v0.0 ts=2002/6/25 3:23
  848k 2003/04/11 D:\Bin\Cygwin\bin\cygcrypto-0.9.7.dll - os=4.0 img=1.0
sys=4.0
                  "cygcrypto-0.9.7.dll" v0.0 ts=2003/4/11 19:33
  645k 2003/04/11 D:\Bin\Cygwin\bin\cygcrypto.dll - os=4.0 img=1.0 sys=4.0
                  "cygcrypto.dll" v0.0 ts=2003/4/11 19:37
  551k 2003/04/02 D:\Bin\Cygwin\bin\cygcurl-2.dll - os=4.0 img=1.0 sys=4.0
                  "cygcurl-2.dll" v0.0 ts=2003/4/3 6:09
  380k 2002/07/24 D:\Bin\Cygwin\bin\cygdb-3.1.dll - os=4.0 img=1.0 sys=4.0
                  "cygdb-3.1.dll" v0.0 ts=2002/7/25 1:24
  487k 2002/07/24 D:\Bin\Cygwin\bin\cygdb_cxx-3.1.dll - os=4.0 img=1.0
sys=4.0
                  "cygdb_cxx-3.1.dll" v0.0 ts=2002/7/25 1:25
   45k 2001/04/25 D:\Bin\Cygwin\bin\cygform5.dll - os=4.0 img=1.0 sys=4.0
                  "cygform5.dll" v0.0 ts=2001/4/25 14:28
   35k 2002/01/09 D:\Bin\Cygwin\bin\cygform6.dll - os=4.0 img=1.0 sys=4.0
                  "cygform6.dll" v0.0 ts=2002/1/9 15:03
   76k 2003/03/09 D:\Bin\Cygwin\bin\cygform7.dll - os=4.0 img=1.0 sys=4.0
                  "cygform7.dll" v0.0 ts=2003/3/10 5:51
   28k 2003/03/22 D:\Bin\Cygwin\bin\cyggdbm-3.dll - os=4.0 img=1.0 sys=4.0
                  "cyggdbm-3.dll" v0.0 ts=2003/3/23 7:19
   19k 2003/03/22 D:\Bin\Cygwin\bin\cyggdbm.dll - os=4.0 img=1.0 sys=4.0
                  "cyggdbm.dll" v0.0 ts=2002/2/20 12:05
   15k 2003/03/22 D:\Bin\Cygwin\bin\cyggdbm_compat-3.dll - os=4.0 img=1.0
sys=4.0
                  "cyggdbm_compat-3.dll" v0.0 ts=2003/3/23 7:22
   17k 2001/06/28 D:\Bin\Cygwin\bin\cyghistory4.dll - os=4.0 img=1.0
sys=4.0
                  "cyghistory4.dll" v0.0 ts=2001/1/7 13:34
   20k 2002/10/10 D:\Bin\Cygwin\bin\cyghistory5.dll - os=4.0 img=1.0
sys=4.0
                  "cyghistory5.dll" v0.0 ts=2002/10/11 2:28
  929k 2002/06/24 D:\Bin\Cygwin\bin\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0
                  "cygiconv-2.dll" v0.0 ts=2002/6/25 3:24
   22k 2001/12/13 D:\Bin\Cygwin\bin\cygintl-1.dll - os=4.0 img=1.0 sys=4.0
                  "cygintl-1.dll" v0.0 ts=2001/12/13 18:28
   28k 2002/09/20 D:\Bin\Cygwin\bin\cygintl-2.dll - os=4.0 img=1.0 sys=4.0
                  "cygintl-2.dll" v0.0 ts=2002/9/20 12:13
   21k 2001/06/20 D:\Bin\Cygwin\bin\cygintl.dll - os=4.0 img=1.0 sys=4.0
                  "cygintl.dll" v0.0 ts=2001/6/21 2:09
   47k 2003/03/09 D:\Bin\Cygwin\bin\cygjbig1.dll - os=4.0 img=1.0 sys=4.0
                  "cygjbig1.dll" v0.0 ts=2003/3/10 6:30
  119k 2002/02/09 D:\Bin\Cygwin\bin\cygjpeg6b.dll - os=4.0 img=1.0 sys=4.0
                  "cygjpeg6b.dll" v0.0 ts=2002/2/9 14:19
   26k 2001/04/25 D:\Bin\Cygwin\bin\cygmenu5.dll - os=4.0 img=1.0 sys=4.0
                  "cygmenu5.dll" v0.0 ts=2001/4/25 14:27
   20k 2002/01/09 D:\Bin\Cygwin\bin\cygmenu6.dll - os=4.0 img=1.0 sys=4.0
                  "cygmenu6.dll" v0.0 ts=2002/1/9 15:03
   48k 2003/03/09 D:\Bin\Cygwin\bin\cygmenu7.dll - os=4.0 img=1.0 sys=4.0
                  "cygmenu7.dll" v0.0 ts=2003/3/10 5:51
  156k 2001/04/25 D:\Bin\Cygwin\bin\cygncurses++5.dll - os=4.0 img=1.0
sys=4.0
                  "cygncurses++5.dll" v0.0 ts=2001/4/25 14:29
  175k 2002/01/09 D:\Bin\Cygwin\bin\cygncurses++6.dll - os=4.0 img=1.0
sys=4.0
                  "cygncurses++6.dll" v0.0 ts=2002/1/9 15:03
  226k 2001/04/25 D:\Bin\Cygwin\bin\cygncurses5.dll - os=4.0 img=1.0
sys=4.0
                  "cygncurses5.dll" v0.0 ts=2001/4/25 14:17
  202k 2002/01/09 D:\Bin\Cygwin\bin\cygncurses6.dll - os=4.0 img=1.0
sys=4.0
                  "cygncurses6.dll" v0.0 ts=2002/1/9 15:03
  284k 2003/03/09 D:\Bin\Cygwin\bin\cygncurses7.dll - os=4.0 img=1.0
sys=4.0
                  "cygncurses7.dll" v0.0 ts=2003/3/10 5:50
   15k 2001/04/25 D:\Bin\Cygwin\bin\cygpanel5.dll - os=4.0 img=1.0 sys=4.0
                  "cygpanel5.dll" v0.0 ts=2001/4/25 14:27
   12k 2002/01/09 D:\Bin\Cygwin\bin\cygpanel6.dll - os=4.0 img=1.0 sys=4.0
                  "cygpanel6.dll" v0.0 ts=2002/1/9 15:03
   31k 2003/03/09 D:\Bin\Cygwin\bin\cygpanel7.dll - os=4.0 img=1.0 sys=4.0
                  "cygpanel7.dll" v0.0 ts=2003/3/10 5:50
   63k 2003/04/11 D:\Bin\Cygwin\bin\cygpcre.dll - os=4.0 img=1.0 sys=4.0
                  "cygpcre.dll" v0.0 ts=2003/4/11 17:31
   61k 2003/04/11 D:\Bin\Cygwin\bin\cygpcreposix.dll - os=4.0 img=1.0
sys=4.0
                  "cygpcreposix.dll" v0.0 ts=2003/4/11 17:31
 1005k 2003/03/30 D:\Bin\Cygwin\bin\cygperl5_8_0.dll - os=4.0 img=1.0
sys=4.0
                  "cygperl5_8_0.dll" v0.0 ts=2003/3/31 0:39
  173k 2003/02/23 D:\Bin\Cygwin\bin\cygpng12.dll - os=4.0 img=1.0 sys=4.0
                  "cygpng12.dll" v0.0 ts=2003/2/24 7:02
   22k 2002/06/09 D:\Bin\Cygwin\bin\cygpopt-0.dll - os=4.0 img=1.0 sys=4.0
                  "cygpopt-0.dll" v0.0 ts=2002/6/9 14:45
  108k 2001/06/28 D:\Bin\Cygwin\bin\cygreadline4.dll - os=4.0 img=1.0
sys=4.0
                  "cygreadline4.dll" v0.0 ts=2001/1/7 13:34
  127k 2002/10/10 D:\Bin\Cygwin\bin\cygreadline5.dll - os=4.0 img=1.0
sys=4.0
                  "cygreadline5.dll" v0.0 ts=2002/10/11 2:28
   66k 2001/11/20 D:\Bin\Cygwin\bin\cygregex.dll - os=4.0 img=1.0 sys=4.0
                  "cygregex.dll" v0.0 ts=2001/11/20 23:44
  176k 2003/04/11 D:\Bin\Cygwin\bin\cygssl-0.9.7.dll - os=4.0 img=1.0
sys=4.0
                  "cygssl-0.9.7.dll" v0.0 ts=2003/4/11 19:33
  165k 2003/04/11 D:\Bin\Cygwin\bin\cygssl.dll - os=4.0 img=1.0 sys=4.0
                  "cygssl.dll" v0.0 ts=2003/4/11 19:37
   50k 2002/03/12 D:\Bin\Cygwin\bin\cygz.dll - os=4.0 img=1.0 sys=4.0
                  "cygz.dll" v0.0 ts=2002/3/12 13:38
  948k 2003/03/18 D:\Bin\Cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=2003/3/18 23:20
    Cygwin DLL version info:
        DLL version: 1.3.22
        DLL epoch: 19
        DLL bad signal mask: 19005
        DLL old termios: 5
        DLL malloc env: 28
        API major: 0
        API minor: 78
        Shared data: 3
        DLL identifier: cygwin1
        Mount registry: 2
        Cygnus registry name: Cygnus Solutions
        Cygwin registry name: Cygwin
        Program options name: Program Options
        Cygwin mount registry name: mounts v2
        Cygdrive flags: cygdrive flags
        Cygdrive prefix: cygdrive prefix
        Cygdrive default prefix:
        Build date: Tue Mar 18 09:20:11 EST 2003
        CVS tag: dontuse-21
        Shared id: cygwin1S3


Cygwin Package Information
Last downloaded files to:
Last downloaded files from:

Package              Version
_update-info-dir     00164-1
ash                  20020731-1
autoconf             2.54-1
autoconf-devel       2.57-1
autoconf-stable      2.13-4
automake             1.7.1-1
automake-devel       1.7.3-1
automake-stable      1.4p5-5
base-files           1.3-1
base-passwd          1.1-1
bash                 2.05b-9
binutils             20030307-1
bzip2                1.0.2-2
clear                1.0-1
cron                 3.0.1-9
crypt                1.0-1
ctags                5.5-3
curl                 7.10.4-1
cygrunsrv            0.96-1
cygutils             1.1.3-1
cygwin               1.3.22-1
cygwin-doc           1.3-4
diff                 1.0-1
diffutils            2.8.1-1
fileutils            4.1-1
findutils            4.1.7-4
flex                 2.5.4-2
gawk                 3.1.2-2
gcc                  3.2-3
gcc-mingw            20020817-5
gdb                  20030303-1
gdbm                 1.8.0-5
gettext              0.11.5-1
grep                 2.5-1
groff                1.18.1-2
gzip                 1.3.3-4
indent               2.2.8-1
inetutils            1.3.2-22
jbigkit              1.4-1
jpeg                 6b-7
less                 378-1
libbz2_1             1.0.2-2
libcharset1          1.8-2
libdb3.1             3.1.17-2
libgdbm              1.8.0-5
libgdbm-devel        1.8.0-5
libgdbm3             1.8.3-1
libiconv2            1.8-2
libintl              0.10.38-3
libintl1             0.10.40-1
libintl2             0.11.5-1
libncurses5          5.2-1
libncurses6          5.2-8
libncurses7          5.3-1
libpng               1.2.5-1
libpng12             1.2.5-1
libpopt0             1.6.4-4
libreadline4         4.1-2
libreadline5         4.3-2
login                1.8-1
m4                   1.4-1
make                 3.79.1-7
man                  1.5j-2
mingw-runtime        3.0-1
mktemp               1.4-1
more                 2.11o-1
ncurses              5.3-1
newlib-man           20020801
openssh              3.6.1p1-1
openssl              0.9.7b-1
openssl096           0.9.6j-1
patch                2.5.8-3
pcre                 4.1-1
perl                 5.8.0-2
popt                 1.6.4-4
readline             4.3-2
regex                4.4-2
rpm                  4.1-1
sed                  4.0.7-1
sh-utils             2.0.15-3
tar                  1.13.25-1
tcltk                20030214-1
tcp_wrappers         7.6-1
tcsh                 6.12.00-5
termcap              20020930-1
terminfo             5.3-2
texinfo              4.2-4
textutils            2.0.21-1
time                 1.7-1
unzip                5.50-2
vim                  6.1.300-1
w32api               2.3-1
wget                 1.8.2-2
which                1.5-1
whois                4.6.2-1
zip                  2.3-2
zlib                 1.1.4-1
zsh                  4.0.6-5

Use -h to see help about each section
--- ここまで ---


__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!  http://bb.yahoo.co.jp/



From naitotk ＠ mars.dti.ne.jp  Wed May 14 13:52:54 2003
From: naitotk ＠ mars.dti.ne.jp (Takashi Naito)
Date: Wed, 14 May 2003 13:52:54 +0900
Subject: [pgsql-jp: 29868] FreeBSD4.8にPostgreSQL7.3.1で
Message-ID: <20030514132800.C7D5.NAITOTK@mars.dti.ne.jp>

内藤と申します。お世話になります。

FreeBSDも何とかインストール出来るスキル程度しか持ち合わせて居ないので非
常に低レベルな質問ではないかと思い恐縮なのですが、FreeBSD 4.8-RELEASEに
PostgreSQL7.3.1を入れようと思いオフィシャルマニュアルの通りにインストー
ルを実施しているのですが、どうもうまくいっていないようなのです。

まず、configureを実行してとくに問題が無いようなので
------
#./configure
checking build system type... i386-unknown-freebsd4.8
checking host system type... i386-unknown-freebsd4.8
checking which template to use... freebsd
   （中略）
checking for collateindex.pl... no
checking for sgmlspl... no
configure: creating ./config.status
config.status: creating GNUmakefile
config.status: creating src/Makefile.global
config.status: creating src/include/pg_config.h
config.status: src/include/pg_config.h is unchanged
config.status: linking ./src/backend/port/tas/dummy.s to src/backend/port/tas.s
config.status: linking ./src/backend/port/dynloader/freebsd.c to src/backend/port/dynloader.c
config.status: linking ./src/backend/port/sysv_sema.c to src/backend/port/pg_sema.c
config.status: linking ./src/backend/port/sysv_shmem.c to src/backend/port/pg_shmem.c
config.status: linking ./src/backend/port/dynloader/freebsd.h to src/include/dynloader.h
config.status: linking ./src/include/port/freebsd.h to src/include/pg_config_os.h
config.status: linking ./src/makefiles/Makefile.freebsd to src/Makefile.port
------

コンパイルを実行すると、checkが始まりループしたような状況になるのです。
------
#gmake
cd . && ./config.status --recheck
running /usr/local/bin/bash ./configure   --no-create --no-recursion
checking build system type... i386-unknown-freebsd4.8
checking host system type... i386-unknown-freebsd4.8
   （中略）
checking for collateindex.pl... no
checking for sgmlspl... no
configure: creating ./config.status
cd . && ./config.status src/Makefile.global
config.status: creating src/Makefile.global
./config.status GNUmakefile
config.status: creating GNUmakefile
cd . && ./config.status --recheck
running /bin/sh ./configure   --no-create --no-recursion
checking build system type... i386-unknown-freebsd4.8
checking host system type... i386-unknown-freebsd4.8
checking which template to use... freebsd
   （中略）
checking for sgmlspl... no
configure: creating ./config.status
cd . && ./config.status src/Makefile.global
config.status: creating src/Makefile.global
./config.status GNUmakefile
config.status: creating GNUmakefile
cd . && ./config.status --recheck
running /usr/local/bin/bash ./configure   --no-create --no-recursion
checking build system type... i386-unknown-freebsd4.8
checking host system type... i386-unknown-freebsd4.8
checking which template to use... freebsd
   （以下同パターンの繰り返し）
------

テストで入れようとしているので非常に非力なマシン（Libretto70）を使ってい
るせいかもしれないのですけれど、1時間以上も繰り返しているのでちょっとお
かしいのでは無いかと思うのですが、なにぶんインストールがはじめてな者なの
で辛抱強く待っていれば終了するかどうかの判断が付きません。

つきましては指揮者の方にアドバイスが頂けたらと思います。
皆様お忙しいとは思いますがどうぞ宜しくお願い致します。

環境まとめ
マシン:Libretto 70(MMX Pentium120MHz 32MB)
OS:FreeBSD 4.8-RELEASE
PostgreSQLソース:v7.3.1
GNU Make:v.3.80

----------------------------------------------------------------------
   内 藤 貴 志  <naitotk ＠ mars.dti.ne.jp>
   @Nifty ID : CQK00312
    Web Site : http://www.mars.dti.ne.jp/~naitotk/




From whatsup ＠ clubaa.com  Wed May 14 14:09:38 2003
From: whatsup ＠ clubaa.com (Y.Uchida)
Date: Wed, 14 May 2003 14:09:38 +0900
Subject: [pgsql-jp: 29869] Re: SELECTプロセスの自動消去は出来ませんか？
Message-ID: <3BEF221A1C587D11284A00205AA8AB27@whatsup.clubaa.com>

内田と申します。

私の元にはIsoさんの２度目のメール依頼届いていない
のですが、
やはりメールは止まったままでしょうか。

同様の経験があるわけではないのですが、個人的に非
常に興味のある内容です。
私は現在、業務ではHP-UXとOracleを使用し、個人的に
自宅でRedHatにPostgreSQLをインストールして勉強し
ております。

WEBのシステムは業務的(社内向け）なもの以外は関
わったことが無いため、
SELECTプロセス中にブラウザを落とすということを考
えたこともありませんでした。
（そのような事はしない前提でのシステムばかりでし
たので）

OracleではPMONというプロセスモニタがいるので、こ
のような場合に対処することもできると思うのですが。
PostgreSQLについてはどうなのでしょう。

Postgreに頼らずにshellでの制御という形もとれなく
は無いと思うのですが、
上記のようなシステムインスタンスがあれば
是非私も教えていただきたいと思っております。

役に立つメールでなくて申し訳ありません。



Powered by CLUBA&A mail. News conscious : www.asahi.com


From sakata.tetsuo ＠ lab.ntt.co.jp  Wed May 14 14:10:26 2003
From: sakata.tetsuo ＠ lab.ntt.co.jp (Tetsuo SAKATA)
Date: Wed, 14 May 2003 14:10:26 +0900
Subject: [pgsql-jp: 29870] Re: FreeBSD4.8にPostgreSQL7.3.1で
References: <20030514132800.C7D5.NAITOTK@mars.dti.ne.jp>
Message-ID: <3EC1CFC2.A4CB3609@lab.ntt.co.jp>

こんにちは．坂田@よこすかです．

直接のお答えではないのですが，FreeBSDをお使いであれば，
Portsからインストールするのが楽だと思いますが，いかがでしょうか？

#同案多数，と思いますが...
Takashi Naito wrote:
> 
> 内藤と申します。お世話になります。
> 
> FreeBSDも何とかインストール出来るスキル程度しか持ち合わせて居ないので非
> 常に低レベルな質問ではないかと思い恐縮なのですが、FreeBSD 4.8-RELEASEに
> PostgreSQL7.3.1を入れようと思いオフィシャルマニュアルの通りにインストー
> ルを実施しているのですが、どうもうまくいっていないようなのです。
-- 
Tetsuo SAKATA, Yokosuka JAPAN.


From yoshint ＠ flab.fujitsu.co.jp  Wed May 14 14:35:23 2003
From: yoshint ＠ flab.fujitsu.co.jp (TOMITA Yoshinori)
Date: Wed, 14 May 2003 14:35:23 +0900
Subject: [pgsql-jp: 29871] Re: FreeBSD4.8にPostgreSQL7.3.1 で
In-Reply-To: <20030514132800.C7D5.NAITOTK@mars.dti.ne.jp> (Takashi Naito's message of "Wed, 14 May 2003 13:52:54 +0900")
References: <20030514132800.C7D5.NAITOTK@mars.dti.ne.jp>
Message-ID: <ywl7k8u146c.fsf@cerberus.proc.flab.fujitsu.co.jp>

富田といいます。


>> On Wed, 14 May 2003 13:52:54 +0900, Takashi Naito
>> <naitotk ＠ mars.dti.ne.jp> said:


Ta> コンパイルを実行すると、checkが始まりループしたような状況になるのです。
Ta> ------
Ta> #gmake
Ta> cd . && ./config.status --recheck
Ta> running /usr/local/bin/bash ./configure   --no-create --no-recursion


＃ ほかにも原因はあるかもしれませんが…

コンピュータの時計や、ファイルのタイムスタンプが異常のときに、Makefile
の依存関係によって、こういう無限ループ症状が起きることがあります。

「date」コマンドで、コンピュータの時刻があっているか、「ls -l」で、ファ
イルのタイムスタンプを確認して、未来の時刻を持ったファイルがないか、確
認してみたらどうでしょうか？


たとえば、今、postgresql-7.3.2で、src/Makefile.global(.in) を見ていて
気が付いたのですが、

$(top_builddir)/config.status: $(top_srcdir)/configure
        cd $(top_builddir) && ./config.status --recheck

というのがあるので、configureのタイムスタンプが未来だと、まさにこれと
同じ症状が発生します。

-- 
---
TOMITA Yoshinori


From yutaka ＠ hi-net.zaq.ne.jp  Wed May 14 14:38:40 2003
From: yutaka ＠ hi-net.zaq.ne.jp (Yutaka tanida)
Date: Wed, 14 May 2003 14:38:40 +0900
Subject: [pgsql-jp: 29872] Re: Windows2000 + Cygwin + PostgreSQL の組み合わせ
In-Reply-To: <20030514112058.F599.M_TERACCHI@yahoo.co.jp>
References: <20030513130436.7B2A.YUTAKA@hi-net.zaq.ne.jp> <20030514112058.F599.M_TERACCHI@yahoo.co.jp>
Message-ID: <20030514143720.BCC2.YUTAKA@hi-net.zaq.ne.jp>

谷田です。

On Wed, 14 May 2003 11:27:06 +0900
M Tera <m_teracchi ＠ yahoo.co.jp> wrote:

>  --- Yutaka tanida <yutaka ＠ hi-net.zaq.ne.jp> からのメッセージ：
> > 解決の糸口になるかどうかは分かりませんが、プロンプトから'cygcheck -svr'
> > したときの出力を見せて頂けますか？
> 
> 私のマシンで 'cygcheck -svr' を実行した結果を以下に示します．
> お手数をおかけして申し訳ありませんが，よろしくお願いいたします．
(snip)

うーん、特に問題はなさそうです。困りました。

Winsockの問題を疑っているのですが、ひょっとして、各種パーソナルファイア
ウォール等をご利用ではないですか？

-- 
Yutaka tanida <yutaka ＠ nonsensecorner.com>
http://www.nonsensecorner.com/



From naitotk ＠ mars.dti.ne.jp  Wed May 14 15:21:16 2003
From: naitotk ＠ mars.dti.ne.jp (Takashi Naito)
Date: Wed, 14 May 2003 15:21:16 +0900
Subject: [pgsql-jp: 29873] Re: FreeBSD4.8にPostgreSQL7.3.1 で
In-Reply-To: <3EC1CFC2.A4CB3609@lab.ntt.co.jp>
References: <20030514132800.C7D5.NAITOTK@mars.dti.ne.jp> <3EC1CFC2.A4CB3609@lab.ntt.co.jp>
Message-ID: <20030514151313.16C0.NAITOTK@mars.dti.ne.jp>

こんにちは返答ありがとうございます。

On Wed, 14 May 2003 14:10:26 +0900
Tetsuo SAKATA <sakata.tetsuo ＠ lab.ntt.co.jp> wrote:

> 直接のお答えではないのですが，FreeBSDをお使いであれば，
> Portsからインストールするのが楽だと思いますが，いかがでしょうか？
> 
> #同案多数，と思いますが...

確かにその通りですね。
オフィシャルのドキュメントを意識するあまりソースからコンパイルすることし
か考えていませんでした。（GNU makeはpackageで入れたくせに（苦笑））
postsからは試してませんがpackageでは入ることを確認しました。
ただ、packageの仕様上バイナリが/usr/local/binに入るのがあまり気持ちよく
ないですが・・・

FreeBSDを使っててなんでportsやpackageに気が行かなかったのか、お恥ずかし
い限りです。

どうもありがとうございました。

----------------------------------------------------------------------
   内 藤 貴 志  <naitotk ＠ mars.dti.ne.jp>
   @Nifty ID : CQK00312
    Web Site : http://www.mars.dti.ne.jp/~naitotk/




From naitotk ＠ mars.dti.ne.jp  Wed May 14 15:28:07 2003
From: naitotk ＠ mars.dti.ne.jp (Takashi Naito)
Date: Wed, 14 May 2003 15:28:07 +0900
Subject: [pgsql-jp: 29874] Re: FreeBSD4.8にPostgreSQL7.3.1 で
In-Reply-To: <ywl7k8u146c.fsf@cerberus.proc.flab.fujitsu.co.jp>
References: <20030514132800.C7D5.NAITOTK@mars.dti.ne.jp> <ywl7k8u146c.fsf@cerberus.proc.flab.fujitsu.co.jp>
Message-ID: <20030514152121.16C3.NAITOTK@mars.dti.ne.jp>

回答ありがとうございます。

On Wed, 14 May 2003 14:35:23 +0900
TOMITA Yoshinori <yoshint ＠ flab.fujitsu.co.jp> wrote:

> ＃ ほかにも原因はあるかもしれませんが…
> 
> コンピュータの時計や、ファイルのタイムスタンプが異常のときに、Makefile
> の依存関係によって、こういう無限ループ症状が起きることがあります。

うわ、まさにこれでした。
試しにdateコマンドを打ってみたら2000年でした(^^;;
いやはや全く気にしていない所でした。（間抜け以外の何者でもないですね）

ということでちゃんとコンパイルが走るようになりました。
どうもありがとうございました。m(__)m

#にしてもそれらしいメッセージが出てくれていたら気づいたんだけど・・・
#でも、自分が間抜けなだけな気もする。

----------------------------------------------------------------------
   内 藤 貴 志  <naitotk ＠ mars.dti.ne.jp>
   @Nifty ID : CQK00312
    Web Site : http://www.mars.dti.ne.jp/~naitotk/




From ogino ＠ sic.co.jp  Wed May 14 15:43:42 2003
From: ogino ＠ sic.co.jp (Ogino)
Date: Wed, 14 May 2003 15:43:42 +0900
Subject: [pgsql-jp: 29875]  Re: Postgresでの日本語検索
In-Reply-To: <u33cjjmb62.wl@lespaul.lantc.cs.fujitsu.co.jp>
References: <u33cjjmb62.wl@lespaul.lantc.cs.fujitsu.co.jp>
Message-ID: <200305140641.PAA05363@asagao.sic.co.jp>

荻野です。自己レスです。


> 加藤＠川崎です。
> 
> (7.3.2ですから) initdb 実行時に --no-locale 指定していない...に一票!!
> 
上記の通りに実行したところ、うまく動作するようになりました。
加藤様、ありがとうございました。

>>松田＠リソナルさま
正規表現も試して見ましたが、うまくいく場合と、そうでない場合が
存在してしまったこと、および私が正規表現に明るくないこと
もあり、加藤様の方法を採用いたしました。

今後は、もう少し調査を綿密にしてから、
皆さんにお願いができるようになりたいと思います。

本当にありがとうございました。

以上





From ohr ＠ yoursys.org  Wed May 14 17:37:41 2003
From: ohr ＠ yoursys.org (ohara takaaki)
Date: Wed, 14 May 2003 17:37:41 +0900
Subject: [pgsql-jp: 29876] Re: text型にinsert   するとpg_atoiエラーが
In-Reply-To: <20030509123141.E6FC.OHR@yoursys.org>
References: <20030509120534.6507.MOCHIZUKI@adcoop.co.jp> <20030509123141.E6FC.OHR@yoursys.org>
Message-ID: <20030514173212.D9F9.OHR@yoursys.org>

ohr です：すみません，期間が空いてしまいました

望月さんの書かれた通りに試してみましたが結果は同じでした．
pg_atoi のエラーがでます．

どうしてテキスト型が pg_atoi されるのか理解できません．
先に出したテーブル内容が少し間違っていたので再度掲載します：

＝＝＝

table1 は
someflg  | smallint |
code     | integer  | not null default nextval('"table1_code_seq"'::text)
textcode | text     |

$textCode = 'str010101954';
$sql = "INSERT INTO table1(someflg, textCode) VALUES(0,'$textCode')";
pg_exec($con, $sql);

とすると，
Warning: pg_exec() query failed: ERROR: pg_atoi: error in
"str010101954": can't parse "str010101954" in ・・・

＝＝＝

SQL初心者なのでお手数かけますが，どうぞヨロシクお願いいたします．
-- 
ohara takaaki <ohr ＠ yoursys.org>



From m_teracchi ＠ yahoo.co.jp  Wed May 14 18:17:39 2003
From: m_teracchi ＠ yahoo.co.jp (M Tera)
Date: Wed, 14 May 2003 18:17:39 +0900
Subject: [pgsql-jp: 29877] Re: Windows2000 + Cygwin + PostgreSQL の組み合わせ
In-Reply-To: <20030514143720.BCC2.YUTAKA@hi-net.zaq.ne.jp>
References: <20030514112058.F599.M_TERACCHI@yahoo.co.jp> <20030514143720.BCC2.YUTAKA@hi-net.zaq.ne.jp>
Message-ID: <20030514175738.BC76.M_TERACCHI@yahoo.co.jp>

寺口です。

 --- Yutaka tanida <yutaka ＠ hi-net.zaq.ne.jp> からのメッセージ：
> Winsockの問題を疑っているのですが、ひょっとして、各種パーソナルファイア
> ウォール等をご利用ではないですか？

自宅マシンには一度 Norton Personal Firewall を入れた経験があります。
が、今はアンインストールしています。
何かしらのゴミが残っているのが問題なのかと思い、手持ちの残りマシン3台 (
全て Windows2000) も含めて試してみました。

結果は次のとおりです。
(タブ [空白8文字分] を使って表を作っております。)
環境		Cygwin		cygipc		postgreSQL	結果
NotePC A	1.3.12		1.3.10-patch	7.2.2-patch	○
NotePC B	1.3.12		1.3.10-patch	7.2.2-patch	×
Desktop A	1.3.12		1.3.10-patch	7.2.2-patch	○
Desktop B	1.3.12		1.3.10-patch	7.2.2-patch	×
Desktop B	1.3.22		1.3.13-patch	7.3.1-patch	×

正常に起動が確認できたマシンは新しく届いた NotePC A と会社で通常利用して
いる Desktop A だけでした。
NotePC B は会社でも家でも利用しているマシンで、Desktop B は家で活躍して
おり、今回メールを出すきっかけになったマシンです。ちなみに、NotePC B に
はパーソナルファイアウォールソフトをインストールしたことはありません。

この表を見る限り、家で使うためにインストールした何かしらのアプリが影響し
ているように思うのですが、今のところ特定するに至っておりません。
谷田様のご指摘では、各種パーソナルファイアウォールが影響しているのではな
いかということですが、他に影響を及ぼしそうなアプリとして何かありますでしょ
うか？

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!  http://bb.yahoo.co.jp/



From hkatsuma ＠ katsudon.info  Wed May 14 18:23:30 2003
From: hkatsuma ＠ katsudon.info (Hidetoshi Katsumata)
Date: Wed, 14 May 2003 18:23:30 +0900
Subject: [pgsql-jp: 29878] Re: Windows2000 + Cygwin + PostgreSQL の組み合わせ
In-Reply-To: <20030514143720.BCC2.YUTAKA@hi-net.zaq.ne.jp>
References: <20030514112058.F599.M_TERACCHI@yahoo.co.jp> <20030514143720.BCC2.YUTAKA@hi-net.zaq.ne.jp>
Message-ID: <20030514181429.6C6E.HKATSUMA@katsudon.info>

勝又です。

私のところでも [pgsql-jp: 29861] と同じと思われる問題が出ています。
とりあえずDBとしては動いている（エラーメッセージ吐きまくりの状態
で、psqlでの接続はできる）ことは確認できますでしょうか?

接続できるようであれば、postgresql.conf に

stats_start_collector = false

と書くことでとりあえずエラーは吐かなくなる、と思います。

明らかに根本的な解決では*ない*ので、私も正しい対応を知りたいので
すが、とりあえずの情報提供です。


[Wed, 14 May 2003 14:38:40 +0900] に、
Yutaka tanida さんが、
メール“[pgsql-jp: 29872] Re: Windows2000 + Cygwin + PostgreSQL  の組み合わせ”でこう書いています：

Yt> Winsockの問題を疑っているのですが、ひょっとして、各種パーソナルファイア
Yt> ウォール等をご利用ではないですか？

私のところではNorton Internet Securityが入っていますが、
Firewall機能を無効にしても出てきてしまったのですよね……

-=-=   勝又 英俊
-=-=    E-Mail : hkatsuma ＠ katsudon.info




From yutaka ＠ hi-net.zaq.ne.jp  Wed May 14 18:34:40 2003
From: yutaka ＠ hi-net.zaq.ne.jp (Yutaka tanida)
Date: Wed, 14 May 2003 18:34:40 +0900
Subject: [pgsql-jp: 29879] Re: Windows2000 + Cygwin + PostgreSQL の組み合わせ
In-Reply-To: <20030514175738.BC76.M_TERACCHI@yahoo.co.jp>
References: <20030514143720.BCC2.YUTAKA@hi-net.zaq.ne.jp> <20030514175738.BC76.M_TERACCHI@yahoo.co.jp>
Message-ID: <20030514182018.BCC5.YUTAKA@hi-net.zaq.ne.jp>

谷田です。推測で申し訳ないのですが。

On Wed, 14 May 2003 18:17:39 +0900
M Tera <m_teracchi ＠ yahoo.co.jp> wrote:

> 自宅マシンには一度 Norton Personal Firewall を入れた経験があります。
> が、今はアンインストールしています。
> 何かしらのゴミが残っているのが問題なのかと思い、手持ちの残りマシン3台 (
> 全て Windows2000) も含めて試してみました。
> 
> 結果は次のとおりです。
> (タブ [空白8文字分] を使って表を作っております。)
> 環境		Cygwin		cygipc		postgreSQL	結果
> NotePC A	1.3.12		1.3.10-patch	7.2.2-patch	○
> NotePC B	1.3.12		1.3.10-patch	7.2.2-patch	×
> Desktop A	1.3.12		1.3.10-patch	7.2.2-patch	○
> Desktop B	1.3.12		1.3.10-patch	7.2.2-patch	×
> Desktop B	1.3.22		1.3.13-patch	7.3.1-patch	×
> 
> 正常に起動が確認できたマシンは新しく届いた NotePC A と会社で通常利用して
> いる Desktop A だけでした。
> NotePC B は会社でも家でも利用しているマシンで、Desktop B は家で活躍して
> おり、今回メールを出すきっかけになったマシンです。ちなみに、NotePC B に
> はパーソナルファイアウォールソフトをインストールしたことはありません。

> この表を見る限り、家で使うためにインストールした何かしらのアプリが影響し
> ているように思うのですが、今のところ特定するに至っておりません。
> 谷田様のご指摘では、各種パーソナルファイアウォールが影響しているのではな
> いかということですが、他に影響を及ぼしそうなアプリとして何かありますでしょ
> うか？

アンチウィルスソフトも問題になるかもしれません。あるいは、service packや
patchの有無も問題になるかもしれません。

あとは、ひょっとすると、起動しない環境だけがユーザー名"root"ではないので
しょうか？

-- 
Yutaka tanida <yutaka ＠ nonsensecorner.com>
http://www.nonsensecorner.com/



From hayakawa ＠ busters.co.jp  Wed May 14 18:35:42 2003
From: hayakawa ＠ busters.co.jp (hayakawa)
Date: Wed, 14 May 2003 18:35:42 +0900
Subject: [pgsql-jp: 29880] Re: Windows2000 + Cygwin + PostgreSQL  の組み合わせ
References: <20030513130436.7B2A.YUTAKA@hi-net.zaq.ne.jp> <20030514112058.F599.M_TERACCHI@yahoo.co.jp> <20030514143720.BCC2.YUTAKA@hi-net.zaq.ne.jp>
Message-ID: <003801c319fc$35870540$0d01a8c0@busters.co.jp>

早川と申します。

私も「Windowsユーザのための PostgreSQL 導入活用ガイド」で
同じ箇所でつまづき　pg_hba.conf　の設定を適切にした所、psqlが動作しました。

pg_hba.confのファイルを開いてご自分の環境に適切な設定をしてあるかご確認され
て下さい。

既に適切な設定をされているのであれば解決方法わかりません。

****************************
HAYAKAWA



From m_teracchi ＠ yahoo.co.jp  Wed May 14 20:00:24 2003
From: m_teracchi ＠ yahoo.co.jp (M Tera)
Date: Wed, 14 May 2003 20:00:24 +0900
Subject: [pgsql-jp: 29881] Re: Windows2000 + Cygwin + PostgreSQL の組み合わせ
In-Reply-To: <003801c319fc$35870540$0d01a8c0@busters.co.jp>
References: <20030514143720.BCC2.YUTAKA@hi-net.zaq.ne.jp> <003801c319fc$35870540$0d01a8c0@busters.co.jp>
Message-ID: <20030514194530.BC78.M_TERACCHI@yahoo.co.jp>

寺口です。

皆さん、いろいろと情報提供ありがとうございます。

 --- Hidetoshi Katsumata <hkatsuma ＠ katsudon.info> 様のメッセージ:
> 私のところでも [pgsql-jp: 29861] と同じと思われる問題が出ています。
> とりあえずDBとしては動いている（エラーメッセージ吐きまくりの状態
> で、psqlでの接続はできる）ことは確認できますでしょうか?
> 
> 接続できるようであれば、postgresql.conf に
> 
> stats_start_collector = false
> 
> と書くことでとりあえずエラーは吐かなくなる、と思います。

私の環境では DB として機能していないようです。
エラーを吐きまくる場合でも、psql での接続はできませんでした。


 --- Yutaka tanida <yutaka ＠ hi-net.zaq.ne.jp> 様のメッセージ:
> アンチウィルスソフトも問題になるかもしれません。あるいは、service packや
> patchの有無も問題になるかもしれません。
> 
> あとは、ひょっとすると、起動しない環境だけがユーザー名"root"ではないので
> しょうか？

どのマシンでも同じバージョンの Norton AntiVirus が起動しております。従っ
て、Norton AntiVirus が原因とは考えづらいのではないかと思います。
Service Pack や Windows パッチに関しても、Windows Update で得られる最新
パッチは全て当てております。
また、全ての環境で "root" ユーザによるテストを行ったので、"root" ユーザ
だから駄目だったということも考えにくいかと思います。


 --- "hayakawa" <hayakawa ＠ busters.co.jp> 様のメッセージ
> pg_hba.confのファイルを開いてご自分の環境に適切な設定をしてあるかご確認され
> て下さい。

pg_hba.conf ファイルはデフォルトの状態から何も触れていませんでした。早速
確認いたしましたが、ローカル環境で利用する分には何ら変更がいらないように
思います。
もし、ローカル環境で利用する場合であっても、追加・変更すべき点がありまし
たら、ご教授願えませんでしょうか？


__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!  http://bb.yahoo.co.jp/



From ohr ＠ yoursys.org  Wed May 14 21:20:39 2003
From: ohr ＠ yoursys.org (ohara takaaki)
Date: Wed, 14 May 2003 21:20:39 +0900
Subject: [pgsql-jp: 29882] pg_atoi エラーが出る
Message-ID: <20030514210514.D9FB.OHR@yoursys.org>

ohr(SQL 初心者）です．

『[pgsql-jp: 29824] text型にinsert するとpg_atoiエラーが』
という題で５月８日，一度投稿させていただきました．

お一方からアドバイスいただけましたが，未解決の
ままなので，もう一度題を変えて投稿しています（すみません）

＝＝＝ 環境
Linux version 2.4.18-17.7.xcustom
Red Hat Linux 7.3 2.96-112
PostgreSQL 7.2.2

で，以下のような table1 を作成しました．

someflg  | smallint |
code     | integer  | not null default nextval('"table1_code_seq"'::text)
textcode | text     |

code は serial 型です．
この table1 に以下のような SQL 文を php スクリプトで作成し
pg_exec に渡します．

$textCode = 'str010101954';
$sql = "INSERT INTO table1(someflg, textCode) VALUES(0,'$textCode')";
pg_exec($con, $sql);

とすると，
Warning: pg_exec() query failed: ERROR: pg_atoi: error in
"str010101954": can't parse "str010101954" in ・

というエラー（警告）が出ます．（データは挿入されています）
TEXT 型にテキストを INSERT してこの pg_atoi エラーが出るのか
解りません．

因みに，
$textCode = '11111111';
などとして「文字」を省略するとエラーはでません．
が，
$textCode = 'aaaaaaaa';
などとすると同じエラーが出ます．

＝＝＝

pg_atoi はアスキー文字を Integer に変換する（？）ぐらい
にしか理解していません．
どのようなことでも構いませんのでアドバイスいただけたら
幸いです．


-- 
ohara takaaki <ohr ＠ yoursys.org>



From mail777 ＠ plala.to  Wed May 14 21:35:16 2003
From: mail777 ＠ plala.to (Mail777)
Date: Wed, 14 May 2003 21:35:16 +0900
Subject: [pgsql-jp: 29883] where句の条件文
Message-ID: <008701c31a15$48f1fe00$6f00a8c0@VERSUS>

はじめて投稿します、BSと申します。

開発環境は、Free BSD、postgresql 7.2.3、php4.2.1です。

うまく書けなくて申し訳ありませんがよろしくお願いします。

select文のwhere句においてフィールドAをsubstirngしたものを3つの条件をつかいA
に足したものを比較します。
簡単に書くと下記のようになります。
Aは1か2か3です。
where (switch(A=1, "あ",A=2,"い",A=3,"う") = あ)
因みに、MS ACCESSでの記述例です。postgresで書く場合どのようにしたらよいので
しょうか？




From sugita ＠ sra.co.jp  Wed May 14 21:42:10 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Wed, 14 May 2003 21:42:10 +0900 (JST)
Subject: [pgsql-jp: 29884] Re: pg_atoi エラーが出る
In-Reply-To: <20030514210514.D9FB.OHR@yoursys.org>
References: <20030514210514.D9FB.OHR@yoursys.org>
Message-ID: <20030514.214210.41637109.sugita@sra.co.jp>

  杉田です。  

From: ohara takaaki <ohr ＠ yoursys.org>
Subject: [pgsql-jp: 29882] pg_atoi エラーが出る
Date: Wed, 14 May 2003 21:20:39 +0900

;;; ohr(SQL 初心者）です．
;;; 
;;; 『[pgsql-jp: 29824] text型にinsert するとpg_atoiエラーが』
;;; という題で５月８日，一度投稿させていただきました．
;;; 
;;; お一方からアドバイスいただけましたが，未解決の
;;; ままなので，もう一度題を変えて投稿しています（すみません）
;;; 
;;; ＝＝＝ 環境
;;; Linux version 2.4.18-17.7.xcustom
;;; Red Hat Linux 7.3 2.96-112
;;; PostgreSQL 7.2.2
;;; 
;;; で，以下のような table1 を作成しました．
;;; 
;;; someflg  | smallint |
;;; code     | integer  | not null default nextval('"table1_code_seq"'::text)
;;; textcode | text     |
;;; 
;;; code は serial 型です．
;;; この table1 に以下のような SQL 文を php スクリプトで作成し
;;; pg_exec に渡します．
;;; 
;;; $textCode = 'str010101954';
;;; $sql = "INSERT INTO table1(someflg, textCode) VALUES(0,'$textCode')";
;;; pg_exec($con, $sql);
;;; 
;;; とすると，
;;; Warning: pg_exec() query failed: ERROR: pg_atoi: error in
;;; "str010101954": can't parse "str010101954" in ・
;;; 
;;; というエラー（警告）が出ます．（データは挿入されています）
;;; TEXT 型にテキストを INSERT してこの pg_atoi エラーが出るのか
;;; 解りません．
;;; 
;;; 因みに，
;;; $textCode = '11111111';
;;; などとして「文字」を省略するとエラーはでません．
;;; が，
;;; $textCode = 'aaaaaaaa';
;;; などとすると同じエラーが出ます．

  どこに、PHP か PostgreSQL、または他の何かのどこに問題があるかを切り分けた方
がよいです。 

    1) psql で直接クエリーを実行して、同様な現象が発生するか確認する。

        試してみましたけれど、発生しませんでした。でも、試してみて下さい。

    2) debug_print_query を true にして、ログを見て、実際にデータベースサーバ
       に渡っているクエリーを確認する。

  2) がどうなっているか分かればとっかかりになるのではないでしょうか?


Kenji Sugita                                      


From toshitaka.iso ＠ hp.com  Wed May 14 21:48:15 2003
From: toshitaka.iso ＠ hp.com (Iso, Toshitaka)
Date: Wed, 14 May 2003 21:48:15 +0900
Subject: [pgsql-jp: 29885] Sequenceの管理用カタログってありますか？
Message-ID: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E02340644@tkoexc02.asiapacific.cpqcorp.net>

いつもお世話になっております。

Version＝7.2.1

つくられたSequenceの情報（現在値、最大/最小値など）を確認したいと
思っているのですが、Sequenceの情報を一覧できるシステムカタログって
ないのでしょうか？

pg_classのrelkindが「S」のものがシーケンスなので、名前の一覧までは
出来るようですが、最大値、最小値、現在値、増分などはどのシステム
カタログで管理されているのでしょうか？

どなたかご存知であればご教授お願いします。

以上です。


From sugita ＠ sra.co.jp  Wed May 14 21:58:52 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Wed, 14 May 2003 21:58:52 +0900 (JST)
Subject: [pgsql-jp: 29886] Re: Sequenceの管理用カタログってありますか？
In-Reply-To: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E02340644@tkoexc02.asiapacific.cpqcorp.net>
References: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E02340644@tkoexc02.asiapacific.cpqcorp.net>
Message-ID: <20030514.215852.104038450.sugita@sra.co.jp>

  杉田です。

From: "Iso, Toshitaka" <toshitaka.iso ＠ hp.com>
Subject: [pgsql-jp: 29885] Sequenceの管理用カタログってありますか？
Date: Wed, 14 May 2003 21:48:15 +0900

;;; Version＝7.2.1
;;; 
;;; つくられたSequenceの情報（現在値、最大/最小値など）を確認したいと
;;; 思っているのですが、Sequenceの情報を一覧できるシステムカタログって
;;; ないのでしょうか？

  pg_class を見てシーケンスのリレーションのカラム情報を表示させればできます。

;;; pg_classのrelkindが「S」のものがシーケンスなので、名前の一覧までは
;;; 出来るようですが、最大値、最小値、現在値、増分などはどのシステム
;;; カタログで管理されているのでしょうか？

  カラム情報については、マニュアルの説明やソースコードから、ひとつのシーケンス
なら、 

    =# select * from 'シーケンス名';

でどうでしょう? クエリーを組み立てれば、全部を表示できます。


Kenji Sugita                                      




From m_teracchi ＠ yahoo.co.jp  Wed May 14 22:27:25 2003
From: m_teracchi ＠ yahoo.co.jp (M Tera)
Date: Wed, 14 May 2003 22:27:25 +0900
Subject: [pgsql-jp: 29887] Re: Windows2000 + Cygwin + PostgreSQL の組み合わせ
In-Reply-To: <20030514194530.BC78.M_TERACCHI@yahoo.co.jp>
References: <003801c319fc$35870540$0d01a8c0@busters.co.jp> <20030514194530.BC78.M_TERACCHI@yahoo.co.jp>
Message-ID: <20030514221608.4C0F.M_TERACCHI@yahoo.co.jp>

寺口です。

自己レスです。
PostgreSQL が正しく起動しないマシンにインストールしているアプリケーショ
ンを検証してみました。
WinSock 関連をいじりそうなアプリとして SSL VPN クライアントがあったので、
それをアンインストールしたところ、psql コマンドが正しく実行されました。
まだ自宅マシンでは確認がとれていませんが、どうも自宅から会社に接続する際に
何気に利用していた VPN クライアント が問題だったようです。

私と同様の問題に遭遇された方は、谷田様のご指摘にありました WinSock の問
題を疑うのが一番のようですね。

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!  http://bb.yahoo.co.jp/



From toshitaka.iso ＠ hp.com  Wed May 14 22:44:27 2003
From: toshitaka.iso ＠ hp.com (Iso, Toshitaka)
Date: Wed, 14 May 2003 22:44:27 +0900
Subject: [pgsql-jp: 29888] Re: Sequenceの管理用カタログってありますか？
Message-ID: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E02340645@tkoexc02.asiapacific.cpqcorp.net>

杉田さん。
いつも大変お世話になっております。

>   カラム情報については、マニュアルの説明やソースコードから、ひとつのシーケンスなら、 
>     =# select * from 'シーケンス名';
> でどうでしょう? クエリーを組み立てれば、全部を表示できます。

select 'select * from '||relname||' union all' from pg_class where relkind='S'
でSQLを作ってとも考えてみたのですが、できればViewのようなものを作って管理したいと考えています。

> pg_class を見てシーケンスのリレーションのカラム情報を表示させればできます。

Ver7.2.1のpg_classには以下のカラムがあるのですが、「シーケンスのリレーションのカラム情報」
とはどのカラムに当たるのか、お手数ですがお教えいただけたら幸いです。

フィールド名
oid
relname
reltype
relowner
relam
relfilenode
relpages
reltuples
reltoastrelid
reltoastidxid
relhasindex
relisshared
relkind
relnatts
relchecks
reltriggers
relukeys
relfkeys
relrefs
relhasoids
relhaspkey
relhasrules
relhassubclass
relacl

以上です。


From ohr ＠ yoursys.org  Wed May 14 23:49:41 2003
From: ohr ＠ yoursys.org (ohara takaaki)
Date: Wed, 14 May 2003 23:49:41 +0900
Subject: [pgsql-jp: 29889] Re: pg_atoi エラーが出る
In-Reply-To: <20030514.214210.41637109.sugita@sra.co.jp>
References: <20030514210514.D9FB.OHR@yoursys.org> <20030514.214210.41637109.sugita@sra.co.jp>
Message-ID: <20030514233437.DA01.OHR@yoursys.org>

ohr です：

杉田さん，アドヴァイスありがとうございます．

>  どこに、PHP か PostgreSQL、または他の何かのどこに問題があるかを切り分けた方
> がよいです。 
> 
>     1) psql で直接クエリーを実行して、同様な現象が発生するか確認する。
> 
>         試してみましたけれど、発生しませんでした。でも、試してみて下さい。
> 
>     2) debug_print_query を true にして、ログを見て、実際にデータベースサーバ
>        に渡っているクエリーを確認する。
> 
>   2) がどうなっているか分かればとっかかりになるのではないでしょうか?

１）を試してみました．
（サーバはレンタルサーバです）
実は例にしているテーブルは簡易的なもので実際はもう少しフィールドが
多いテーブルなのですが，同じテーブルを作成して，php からだとエラーに
なる SQL を直接 psql で実行してみましたが，データはすんなり挿入され，
エラーも表示されませんでした．

２）についてはちょっとよく解らないです＾＾；（一般ユーザが操作できる
領域ですか？）
一応，ブラウザには渡った SQL を表示させています．

＝＝＝

ということで php から実行されるときに問題が発生しているのかな
という思いがしてきましたが，未だ定かではありませんし，「とっかかり」
がつかめていません＾＾；

OS,Postgres,php のヴァージョン等はそれぞれ異なっていますが，別のサーバ
（自サーバ）ではこのエラーを見ていません．
テキスト型にテキストを insert すると pg_atoi 関数が呼び出される
ようになっているのでしょうか？（とんちんかん？）

継続して，よろしくお願いします．
-- 
ohara takaaki <ohr ＠ yoursys.org>



From formsoft ＠ tcct.zaq.ne.jp  Thu May 15 05:48:46 2003
From: formsoft ＠ tcct.zaq.ne.jp (Ryo Kunieda)
Date: Thu, 15 May 2003 05:48:46 +0900
Subject: [pgsql-jp: 29890] INSERTで作成したカラムのSERIAL 値の取り出し方
Message-ID: <v04210a01bae8563c5492@[192.168.128.10]>

初めまして。本日より参加させていただいています。よろしくお願いいたします。

かなり昔に Infomix-SQL などを扱ったことがあるので一応SQLについては概要は分か
っているつもりですが、いわばリハビリ中の状態です。

早速ですが表題の件でお教えいただけませんでしょうか。

たとえば次のようなユーザー情報のテーブルがあるとします。

CREATE TABLE member (
id SERIAL PRIMARY KEY,
name varchar(16),
);

ここに
INSERT INTO member (name) VALUES('Ryo');
などとすれば「Ryo」さんが登録されて id に顧客番号が自動的に振られるのを期待
できると思います。
では、このSERIALの値はどのように取得すればいいのでしょうか？
「INSERT」の直後に name で検索することも考えたのですが、既に同じ名前のユーザ
ー情報が登録されていた場合（当然あり得ないことではありません。その為の顧客番
号なんですから）難しいことになるでしょう。
INSERTのTIMESTAMPを記録しておく方法も考えましたが、もし他のクライアントから
同時に登録処理が起きた場合（無いとは思いますが・・・）致命的なバグになってし
まいます。

こういう場合トランザクションしないといけないのでしょうか？
そもそも、登録したデータのユニーク値をその場で得られないというのはなんか変な
気がして、何か見落としがあるのではと思っていろいろ検索してみましたが解りませ
んでした。

こういう場合のセオリーなどがあればお教え下さい。

よろしくお願いいたします。


----------------------------------------------------------------
formsoft ＠ tcct.zaq.ne.jp (FormSoftware)
Ryo Kunieda -  FormSoftware
Osaka, Japan　Tel:+81-6-6335-6266 Fax:+81-6-6335-6276
----------------------------------------------------------------


From hi-takada ＠ k5.dion.ne.jp  Thu May 15 06:28:11 2003
From: hi-takada ＠ k5.dion.ne.jp (Hiroki Takada)
Date: Thu, 15 May 2003 06:28:11 +0900
Subject: [pgsql-jp: 29891] Re: INSERTで作成したカラムのSERIAL 値の取り出し方
In-Reply-To: <v04210a01bae8563c5492@[192.168.128.10]>
References: <v04210a01bae8563c5492@[192.168.128.10]>
Message-ID: <20030514212811.GA1194%hi-takada@k5.dion.ne.jp>

高田ともうします。

こんにちは。

> INSERT INTO member (name) VALUES('Ryo');
> などとすれば「Ryo」さんが登録されて id に顧客番号が自動的に振られるのを期待
> できると思います。
> では、このSERIALの値はどのように取得すればいいのでしょうか？

SELECT currval('シーケンス名');

で取得できます。この例だと、

SELECT currval('member_id_seq');

となります。

> INSERTのTIMESTAMPを記録しておく方法も考えましたが、もし他のクライアントから
> 同時に登録処理が起きた場合（無いとは思いますが・・・）致命的なバグになってし
> まいます。

currval は現在のセッションにおいて、 最後に実行された nextval の値が
保存されているので、他のセッションで member テーブルにレコードが追加
されたかどうかをケアする必要がありません。


From iakio ＠ pjam.jpweb.net  Thu May 15 09:17:27 2003
From: iakio ＠ pjam.jpweb.net (ISHIDA Akio)
Date: Thu, 15 May 2003 09:17:27 +0900
Subject: [pgsql-jp: 29892] Re: where句の条件文
In-Reply-To: <008701c31a15$48f1fe00$6f00a8c0@VERSUS>
References: <008701c31a15$48f1fe00$6f00a8c0@VERSUS>
Message-ID: <20030515091727.771C2E58.iakio@pjam.jpweb.net>

こんにちは。石田@苫小牧市です。

"Mail777" <mail777 ＠ plala.to> wrote:
(2003/05/14 21:35)

> はじめて投稿します、BSと申します。
> 
> 開発環境は、Free BSD、postgresql 7.2.3、php4.2.1です。
> 
> うまく書けなくて申し訳ありませんがよろしくお願いします。
> 
> select文のwhere句においてフィールドAをsubstirngしたものを3つの条件をつかいA
> に足したものを比較します。
> 簡単に書くと下記のようになります。
> Aは1か2か3です。
> where (switch(A=1, "あ",A=2,"い",A=3,"う") = あ)
> 因みに、MS ACCESSでの記述例です。postgresで書く場合どのようにしたらよいので
> しょうか？

CASE 文でできないでしょうか？
http://www.postgresql.jp/document/pg721doc/user/functions-conditional.
html

WHERE CASE
  WHEN a = 'a' THEN 'あ'
  WHEN a = 2 THEN 'い'
  WHEN a = 3 THEN 'う'
  END = 'あ'

--
ISHIDA Akio<iakio ＠ pjam.jpweb.net>



From kishi ＠ b-b-net.com  Thu May 15 11:15:06 2003
From: kishi ＠ b-b-net.com (Emiko Kishi)
Date: Thu, 15 May 2003 11:15:06 +0900
Subject: [pgsql-jp: 29893] 使用しているファイルサイズを調べたい
Message-ID: <MHEMLLOEBIEENMDDBMHJKEINCMAA.kishi@b-b-net.com>

はじめまして、岸と申します。
このMLは少し前から拝見していましたが、投稿は初めてです。

レンタルサーバで運用に向けて構築中のWEBシステムで、
「どのぐらいの会員数でどのぐらいの期間運用を続けると、
サーバ業者より割り当てられているディスク容量を使い切るか」
を見積もろうとしています。
環境は、PostgreSQL 7.2.3 (FreeBSD 4.7 / Apache 1.3.27)です。

このMLの過去ログで、論理値の計算方法を詳細に説明しておられる
投稿を拝見し、今回のシステムでの論理値を計算してみました。
その結果安心のできる値が出たのですが、念のため実際に
ある程度のダミーデータを投入し、実測値と比較しようとしています。

そのとき実測値として、「pg_class.relpagesを合計したもの×8kb」
を使用しようとしていますが、これは妥当な値なのでしょうか？
私が調べた限りでは、VACUUM ANALYZE した直後であれば
正しい値が入っているように思えたのですが・・・。
# レンタルサーバのため、データフォルダを自由に見ることができません。

参考にしたページ：
PostgreSQL 7.2.3 ユーザガイド Chapter 11. 性能に関するヒント
11.2. プランナで使用される統計情報
http://www.postgresql.jp/document/pg721doc/user/planner-stats.html
PostgreSQL 7.2.3 開発者ガイド Chapter 3. システムカタログ
3.5. pg_class
http://www.postgresql.jp/document/pg721doc/developer/catalog-pg-class.ht
ml

また、他に気をつけるべきことはありますでしょうか？
もしくは「本来こうするべき」といったやり方があるのでしょうか？

こういった見積は初めてで、周囲に頼れる方もいないため独学です。
先輩諸氏のご意見・ツッコミ等をいただけますと、大変助かります。
よろしくお願いします。

-----
岸恵美子 kishi ＠ b-b-net.com





From mochizuki ＠ adcoop.co.jp  Thu May 15 11:24:20 2003
From: mochizuki ＠ adcoop.co.jp (Takashi Mochizuki)
Date: Thu, 15 May 2003 11:24:20 +0900
Subject: [pgsql-jp: 29894] Re: pg_atoi エラーが出る
In-Reply-To: <20030514210514.D9FB.OHR@yoursys.org>
References: <20030514210514.D9FB.OHR@yoursys.org>
Message-ID: <20030515110902.D5DF.MOCHIZUKI@adcoop.co.jp>

望月です。
恥ずかしながら、私の投稿
$sql = "insert into hoge (someflg,code,textcode) values (0,nextval('code'),'$textcode')";
は誤りでした。
お詫びして訂正いたします。

$textCode = 'str010101954';
$sql = "INSERT INTO table1(someflg, textCode) VALUES(0,'$textCode')";
pg_exec($con, $sql);

で、pg_atoiのエラー がでるのは上記以外のカラムが実際は存在するのではない
でしょうか？
insertする順番がずれているのが原因かと思います。

以下テスト用(構成：PostgreSQL-7.3.2,Apache_1.3.27,PHP 4.3.2RC1)

                             Table "public.hoge"
  Column  |   Type   |                       Modifiers
----------+----------+--------------------------------------------------------
 someflg  | smallint |
 code     | integer  | not null default nextval('public.hoge_code_seq'::text)
 textcode | text     |

serial_test=# select * from hoge;
 someflg | code |   textcode
---------+------+--------------
       0 |    1 | str010101954
       2 |    2 | abcde
       2 |    3 | abcde
       4 |    4 | abcde
       5 |    5 | abcde
       5 |    6 | abcde
       5 |    7 | abcde
      10 |    8 | abcde
(8 rows)

<?php
$connectdbname = "host=127.0.0.1 port=5432 user=nobody dbname=serial_test";

$someflg = $_POST["someflg"];
$textcode= $_POST["textcode"];

$dbhandle = pg_connect($connectdbname) or die("dbhandle failed");
$sql = "insert into hoge (someflg,textcode) values ('$someflg','$textcode')";
pg_query($dbhandle,"BEGIN");
pg_query($dbhandle,$sql);
pg_query($dbhandle,"COMMIT");

?>
<html>
 <head>
  <title>シリアル番号</title>
 </head>
<body>
<h1>シリアル番号</h1>
<table border="1">
 <tr valign=top align=left>
  <th>番号</th>
  <th>テキスト</th>
 </tr>
 <form method="post" action="<?php print("http://{$_SERVER['HTTP_HOST']}{$_SERVER['PHP_SELF']}"); ?>">
 <tr valign=middle align=left>
  <td><input type="text" name="someflg" size=12 maxlength=32 value="<?php print("$someflg"); ?>"></td>
  <td><input type="text" name="textcode" size=12 maxlength=32 value="<?php print("$textcode"); ?>"></td>
  <td align=right><input type="submit" name="serial_test" value="シリアル番号"></td>
 </tr>
 </form>
</table>
</body>
</html>

以上


From sugita ＠ sra.co.jp  Thu May 15 12:59:45 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Thu, 15 May 2003 12:59:45 +0900 (JST)
Subject: [pgsql-jp: 29895] Re: 使用しているファイルサイズを調べたい
In-Reply-To: <20030515.125418.71086014.sugita@sra.co.jp>
References: <MHEMLLOEBIEENMDDBMHJKEINCMAA.kishi@b-b-net.com>
	<20030515.125418.71086014.sugita@sra.co.jp>
Message-ID: <20030515.125945.85415890.sugita@sra.co.jp>

From: sugita ＠ sra.co.jp
Subject: Re: [pgsql-jp: 29893] 使用しているファイルサイズを調べたい
Date: Thu, 15 May 2003 12:54:18 +0900 (JST)

  杉田です。

From: "Emiko Kishi" <kishi ＠ b-b-net.com>
Subject: [pgsql-jp: 29893] 使用しているファイルサイズを調べたい
Date: Thu, 15 May 2003 11:15:06 +0900

;;; そのとき実測値として、「pg_class.relpagesを合計したもの×8kb」
;;; を使用しようとしていますが、これは妥当な値なのでしょうか？

  はい。

;;; 私が調べた限りでは、VACUUM ANALYZE した直後であれば
;;; 正しい値が入っているように思えたのですが・・・。
;;; # レンタルサーバのため、データフォルダを自由に見ることができません。

  http://www.sra.co.jp/people/sugita/pg_chkrel.tgz は、テーブルディスク使用量
及びテーブルとインデックスの不要領域計測スクリプトです。このスクリプトを読んで
頂くとどのようにすればよいか分かると思います。このスクリプトでは、リモート接続
した場合には、ファイル領域の実サイズは調べませんので、データフォルダが見えなく
ても使えます。

  PostgreSQL 7.0〜7.3 で使用できます。pg_chkrel のコマンドラインシンタックスは、
以下のようになっています。

	$ pg_chkrel --help
	Usage:
	  pg_chkrel [options] [dbname [username]]

	Options:
	  -D <dbdir>      Specify database directory (default: /Volumes/Home/Users/pgsql/7.3.1/data)
	  -d <dbname>     Specify database name to connect to (default: sugita)
	  -h <host>       Specify database server host (default: domain socket)
	  -p <port>       Specify database server port (default: hardwired)
	  -U <username>   Specify database username (default: sugita)
	  -k {r|i|a}      Specify relation (r), index (i) or all (a) (default: a)
	  -s <pagesize>   Specify page size of heap file (default: 8 KB)
	  --help          show this help, then exit
	  --version       output version information, then exit
	$ 

  表示欄は以下のようになっています。

    Relation Name          … テーブル、インデックス、TOAST の名前。
    File Name              … テーブル、インデックス、TOAST のファイル名。
    Tuples                 … 統計情報のタプル数。
    Pages                  … 統計情報のページ数。括弧内は、PostgreSQL 7.2 で
    			      有効で、テーブルの場合、そのインデックスと TOAST
    			      を含むテーブル占有ディスク量。
    File Size              … ローカル接続の場合には、実際のファイルサイズ (KB)。
    	 		      リモート接続の場合には、Tuples * Pages * ページ
    			      サイズ。 
    Size/Tuples            … File Size/Tuples (KB)。
    Tuple Size             … 統計情報の平均タプル長 (KB)。PostgreSQL 7.2 以上
    	  		      で有効。

  VACUUM ANALYZE を行った後に pg_chkrel で計測します。判断方法は、Tuples があ
る程度多い場合に、Size/Tuples が大き過ぎる場合は、ゴミの量が多いと判断できます。
PostgreSQL 7.2 以上の場合には、統計情報の平均タプルサイズ Tuple Size との比較
でも判断可能です。

  以下は、PostgreSQL 7.3 での実行例です。数千回の一時テーブルを作成した直後で、
pg_catalog.pg_attribute_relid_attnam_index は Tuples が 1290 個ですが、
Size/Tuples が 16 KB と極端に大きくなっています。インデックスは、ゴミがない場
合に、通常 60% が有効領域であることを考えても、かなりゴミ領域があると判断でき
ます。このことは、REINDEX 後の pg_chkrel で 99B に減っている事からも分かります。

    ====  pg_chkrel の実行結果  ====       
    Date               : Wed May  7 11:45:11 JST 2003
    Host               : localhost
    User               : sugita
    Database Host      : default (local)
    Database Name      : sugita (16976)
    Database User      : sugita (1)
    Database Port      : default
    Database Directory : /opt/pgsql/7.3.1/data
    Version            : PostgreSQL 7.3.1 on i686-pc-linux-gnu, compiled by GCC 2.95.3
    Page Size (KB)     : 8 (default)

    Relation Name                                File Name  Tuples     Pages                   File Size  Size/Tuples Tuple Size
    r pg_catalog.pg_aggregate                         16406         60          1 (         3)          8      0.133      0.027
    i pg_catalog.pg_aggregate_fnoid_index             16600         60          2 (         2)         16      0.133      -.---
    r pg_catalog.pg_am                                16396          4          1 (         5)          8      2.000      0.118
    i pg_catalog.pg_am_name_index                     16601          4          2 (         2)         16      2.000      -.---
    i pg_catalog.pg_am_oid_index                      16602          4          2 (         2)         16      2.000      -.---
    r pg_catalog.pg_amop                              16398        180          1 (         5)          8      0.044      0.011
    i pg_catalog.pg_amop_opc_opr_index                16603        180          2 (         2)         16      0.044      -.---
    i pg_catalog.pg_amop_opc_strategy_index           16604        180          2 (         2)         16      0.044      -.---
    r pg_catalog.pg_amproc                            16400         57          1 (         3)          8      0.140      0.010
    i pg_catalog.pg_amproc_opc_procnum_index          16605         57          2 (         2)         16      0.140      -.---
    r pg_catalog.pg_attrdef                           16384          1          1 (         6)          8      8.000      0.336
    i pg_catalog.pg_attrdef_adrelid_adnum_index       16606          1          2 (         2)         16      8.000      -.---
    i pg_catalog.pg_attrdef_oid_index                 16607          1          2 (         2)         16      8.000      -.---
    r pg_catalog.pg_attribute                          1249       1290         22 (      3240)        176      0.136      0.068
    i pg_catalog.pg_attribute_relid_attnam_index      16608       1290       2578 (      2578)      20624     15.981      -.---
    i pg_catalog.pg_attribute_relid_attnum_index      16609       1290        640 (       640)       5120      3.963      -.---
    ...
    r public.c1                                     1046332       1002         12 (        41)         96      0.096      0.004
    i public.c1_id_2_index                          1047342       1002          5 (         5)         40      0.032      -.---
    i public.c1_id_index                            1046337       1002          5 (         5)         40      0.032      -.---
    r public.c2                                     1347362    1000000       4406 (      8792)      35248      0.035      0.004
    i public.c2_id_1_index                          2347379    1000000       2193 (      2193)      17544      0.018      -.---
    i public.c2_id_index                            2347378    1000000       2193 (      2193)      17544      0.018      -.---
    ...
    Total                                                                                          169512

    ====  REINDEX、VACUUM ANALYZE 後の pg_cherel の実行結果  ====       
    Date               : Wed May  7 13:45:15 JST 2003
    Host               : localhost
    User               : sugita
    Database Host      : default (local)
    Database Name      : sugita (16976)
    Database User      : sugita (1)
    Database Port      : default
    Database Directory : /opt/pgsql/7.3.1/data
    Version            : PostgreSQL 7.3.1 on i686-pc-linux-gnu, compiled by GCC 2.95.3
    Page Size (KB)     : 8 (default)

    Relation Name                                File Name  Tuples     Pages                   File Size  Size/Tuples Tuple Size
    r pg_catalog.pg_aggregate                         16406         60          1 (         3)          8      0.133      0.027
    i pg_catalog.pg_aggregate_fnoid_index           6727465         60          2 (         2)         16      0.133      -.---
    r pg_catalog.pg_am                                16396          4          1 (         5)          8      2.000      0.118
    i pg_catalog.pg_am_name_index                   6727459          4          2 (         2)         16      2.000      -.---
    i pg_catalog.pg_am_oid_index                    6727460          4          2 (         2)         16      2.000      -.---
    r pg_catalog.pg_amop                              16398        180          1 (         5)          8      0.044      0.011
    i pg_catalog.pg_amop_opc_opr_index              6727461        180          2 (         2)         16      0.044      -.---
    i pg_catalog.pg_amop_opc_strategy_index           16604        180          2 (         2)         16      0.044      -.---
    r pg_catalog.pg_amproc                            16400         57          1 (         3)          8      0.140      0.010
    i pg_catalog.pg_amproc_opc_procnum_index          16605         57          2 (         2)         16      0.140      -.---
    r pg_catalog.pg_attrdef                           16384          1          1 (         6)          8      8.000      0.336
    i pg_catalog.pg_attrdef_adrelid_adnum_index     6727479          1          2 (         2)         16      8.000      -.---
    i pg_catalog.pg_attrdef_oid_index               6727480          1          2 (         2)         16      8.000      -.---
    r pg_catalog.pg_attribute                          1249       1290         22 (        45)        176      0.136      0.068
    i pg_catalog.pg_attribute_relid_attnam_index    6727453       1290         17 (        17)        136      0.099      -.---
    i pg_catalog.pg_attribute_relid_attnum_index      16609       1290          6 (         6)         48      0.031      -.---
    ...
    r public.c1                                     1046332       1002         12 (        41)         96      0.096      0.004
    i public.c1_id_2_index                          1047342       1002          5 (         5)         40      0.032      -.---
    i public.c1_id_index                            1046337       1002          5 (         5)         40      0.032      -.---
    r public.c2                                     1347362    1000000       4406 (      8792)      35248      0.035      0.004
    i public.c2_id_1_index                          2347379    1000000       2193 (      2193)      17544      0.018      -.---
    i public.c2_id_index                            2347378    1000000       2193 (      2193)      17544      0.018      -.---
    ...
    Total                                                                                          134264

Kenji Sugita                                      



From kishi ＠ b-b-net.com  Thu May 15 13:42:07 2003
From: kishi ＠ b-b-net.com (Emiko Kishi)
Date: Thu, 15 May 2003 13:42:07 +0900
Subject: [pgsql-jp: 29896] Re: 使用しているファイルサイズを調べたい
In-Reply-To: <20030515.125945.85415890.sugita@sra.co.jp>
Message-ID: <MHEMLLOEBIEENMDDBMHJAEJCCMAA.kishi@b-b-net.com>

おつかれさまです、岸です。

杉田さま、返信をありがとうございます。

> ;;; そのとき実測値として、「pg_class.relpagesを合計したもの×8kb」
> ;;; を使用しようとしていますが、これは妥当な値なのでしょうか？
>
>   はい。

テーブルの解説で「推測値」とわざわざ断ってあったため、少し不安でした。
妥当であるようなら、この値で測ってみようと思います。


> ;;; 私が調べた限りでは、VACUUM ANALYZE した直後であれば
> ;;; 正しい値が入っているように思えたのですが・・・。
> ;;; # レンタルサーバのため、データフォルダを自由に見ることができません
> 。
>
>   http://www.sra.co.jp/people/sugita/pg_chkrel.tgz は、テーブルディス
ク
> 使用量
> 及びテーブルとインデックスの不要領域計測スクリプトです。このスクリプト
> を読んで
> 頂くとどのようにすればよいか分かると思います。このスクリプトでは、リモ
> ート接続
> した場合には、ファイル領域の実サイズは調べませんので、データフォルダが
> 見えなく
> ても使えます。
>
[実例の引用は省略させていただきました]

ご指摘ありがとうございます。
不要領域には、頭が回っていませんでした。

スクリプトは、早速ダウンロードいたしました。
ダミーデータ投入・削除の時に使わせていただきます。
# その前にスクリプトの中身を勉強、勉強 :-)

ありがとうございます！

-----
岸恵美子 kishi ＠ b-b-net.com





From sugita ＠ sra.co.jp  Thu May 15 14:40:29 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Thu, 15 May 2003 14:40:29 +0900 (JST)
Subject: [pgsql-jp: 29897] Re: Sequenceの管理用カタログってありますか？
In-Reply-To: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E02340645@tkoexc02.asiapacific.cpqcorp.net>
References: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E02340645@tkoexc02.asiapacific.cpqcorp.net>
Message-ID: <20030515.144029.39154082.sugita@sra.co.jp>

From: "Iso, Toshitaka" <toshitaka.iso ＠ hp.com>
Subject: [pgsql-jp: 29888] Re: Sequenceの管理用カタログってありますか？
Date: Wed, 14 May 2003 22:44:27 +0900

;;; 杉田さん。
;;; いつも大変お世話になっております。

  こちらこそです。

;;; >   カラム情報については、マニュアルの説明やソースコードから、ひとつのシーケンスなら、 
;;; >     =# select * from 'シーケンス名';
;;; > でどうでしょう? クエリーを組み立てれば、全部を表示できます。
;;; 
;;; select 'select * from '||relname||' union all' from pg_class where relkind='S'
;;; でSQLを作ってとも考えてみたのですが、できればViewのようなものを作って管理したいと考えています。

  View ではありませんけれど、スクリプトで、このような感じではどうでしょう。

$ psql -t -A -F ' ' -c '\ds' | while read relname rest ; do echo "union"; echo "select * from $relname" ; done | tail +2 | psql
  sequence_name  | last_value | increment_by |      max_value      | min_value | cache_value | log_cnt | is_cycled | is_called 
-----------------+------------+--------------+---------------------+-----------+-------------+---------+-----------+-----------
 seq             |          1 |            1 | 9223372036854775807 |         1 |           1 |       1 | f         | f
 table1_code_seq |          2 |            1 | 9223372036854775807 |         1 |           1 |      32 | f         | t
(2 rows)

$ 

;;; > pg_class を見てシーケンスのリレーションのカラム情報を表示させればできます。
;;; 
;;; Ver7.2.1のpg_classには以下のカラムがあるのですが、「シーケンスのリレーションのカラム情報」
;;; とはどのカラムに当たるのか、お手数ですがお教えいただけたら幸いです。

  シーケンスの情報はそれぞれのシーケンスを SELECT すると分かります。

=# \d seq
     Sequence "seq"
    Column     |  Type   
---------------+---------
 sequence_name | name
 last_value    | bigint
 increment_by  | bigint
 max_value     | bigint
 min_value     | bigint
 cache_value   | bigint
 log_cnt       | bigint
 is_cycled     | boolean
 is_called     | boolean

=# 


Kenji Sugita                                      


From sugita ＠ sra.co.jp  Thu May 15 14:59:41 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Thu, 15 May 2003 14:59:41 +0900 (JST)
Subject: [pgsql-jp: 29898] Re: pg_atoi エラーが出る
In-Reply-To: <20030514233437.DA01.OHR@yoursys.org>
References: <20030514210514.D9FB.OHR@yoursys.org>
	<20030514.214210.41637109.sugita@sra.co.jp>
	<20030514233437.DA01.OHR@yoursys.org>
Message-ID: <20030515.145941.59650911.sugita@sra.co.jp>

  杉田です。

From: ohara takaaki <ohr ＠ yoursys.org>
Subject: [pgsql-jp: 29889] Re: pg_atoi エラーが出る
Date: Wed, 14 May 2003 23:49:41 +0900

;;; >     2) debug_print_query を true にして、ログを見て、実際にデータベースサーバ
;;; >        に渡っているクエリーを確認する。
...
;;; ２）についてはちょっとよく解らないです＾＾；（一般ユーザが操作できる
;;; 領域ですか？）

  ログを採っていて、そのログを見る事ができれば可能です。

;;; 一応，ブラウザには渡った SQL を表示させています．

  2) で、サーバが受け取ったものが実際に何かが分かります。


Kenji Sugita                                      


From mail777 ＠ plala.to  Thu May 15 15:10:52 2003
From: mail777 ＠ plala.to (Mail777)
Date: Thu, 15 May 2003 15:10:52 +0900
Subject: [pgsql-jp: 29899] Re: where句の条件文
References: <008701c31a15$48f1fe00$6f00a8c0@VERSUS> <20030515091727.771C2E58.iakio@pjam.jpweb.net>
Message-ID: <000501c31aa8$bda5bf50$6f00a8c0@VERSUS>

石田様

ご教授ありがとうございます。
やはりcase文はwhere句でも使えるのですね。

いろいろ試してみた結果ようやくできました。
ありがとうございました。

> こんにちは。石田@苫小牧市です。
>
> "Mail777" <mail777 ＠ plala.to> wrote:
> (2003/05/14 21:35)
>
> > はじめて投稿します、BSと申します。
> >
> > 開発環境は、Free BSD、postgresql 7.2.3、php4.2.1です。
> >
> > うまく書けなくて申し訳ありませんがよろしくお願いします。
> >
> > select文のwhere句においてフィールドAをsubstirngしたものを3つの条件をつか
いA
> > に足したものを比較します。
> > 簡単に書くと下記のようになります。
> > Aは1か2か3です。
> > where (switch(A=1, "あ",A=2,"い",A=3,"う") = あ)
> > 因みに、MS ACCESSでの記述例です。postgresで書く場合どのようにしたらよい
ので
> > しょうか？
>
> CASE 文でできないでしょうか？
> http://www.postgresql.jp/document/pg721doc/user/functions-conditional.
> html
>
> WHERE CASE
>   WHEN a = 'a' THEN 'あ'
>   WHEN a = 2 THEN 'い'
>   WHEN a = 3 THEN 'う'
>   END = 'あ'
>
> --
> ISHIDA Akio<iakio ＠ pjam.jpweb.net>
>




From sugita ＠ sra.co.jp  Thu May 15 15:48:04 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Thu, 15 May 2003 15:48:04 +0900 (JST)
Subject: [pgsql-jp: 29900] Re: 使用しているファイルサイズを調べたい
In-Reply-To: <MHEMLLOEBIEENMDDBMHJAEJCCMAA.kishi@b-b-net.com>
References: <20030515.125945.85415890.sugita@sra.co.jp>
	<MHEMLLOEBIEENMDDBMHJAEJCCMAA.kishi@b-b-net.com>
Message-ID: <20030515.154804.35663049.sugita@sra.co.jp>

  杉田です。

From: "Emiko Kishi" <kishi ＠ b-b-net.com>
Subject: [pgsql-jp: 29896] Re: 使用しているファイルサイズを調べたい
Date: Thu, 15 May 2003 13:42:07 +0900

;;; > ;;; そのとき実測値として、「pg_class.relpagesを合計したもの×8kb」
;;; > ;;; を使用しようとしていますが、これは妥当な値なのでしょうか？
;;; >
;;; >   はい。
;;; 
;;; テーブルの解説で「推測値」とわざわざ断ってあったため、少し不安でした。
;;; 妥当であるようなら、この値で測ってみようと思います。

  以下の試された通り、VACUUM ANALYZE の直後ならば妥当な値です。

;;; > ;;; 私が調べた限りでは、VACUUM ANALYZE した直後であれば
;;; > ;;; 正しい値が入っているように思えたのですが・・・。
  

Kenji Sugita                                      


From fit0445 ＠ fitec.co.jp  Thu May 15 15:53:01 2003
From: fit0445 ＠ fitec.co.jp (Hiroshi Watanabe)
Date: Thu, 15 May 2003 15:53:01 +0900
Subject: [pgsql-jp: 29901] ORACLEでいう DUAL 表は？
Message-ID: <20030515155118.9C87.FIT0445@fitec.co.jp>

　渡辺と申します。

　ORACLE では DUAL という表があり

　SELECT SYSDATE FROM DUAL ;

　見たいに使っていましたが、postgresql では
　そのような表はあるのでしょうか？





From sugita ＠ sra.co.jp  Thu May 15 15:59:21 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Thu, 15 May 2003 15:59:21 +0900 (JST)
Subject: [pgsql-jp: 29902] Re: ORACLEでいう DUAL 表は？
In-Reply-To: <20030515155118.9C87.FIT0445@fitec.co.jp>
References: <20030515155118.9C87.FIT0445@fitec.co.jp>
Message-ID: <20030515.155921.38714150.sugita@sra.co.jp>

  杉田です。

From: Hiroshi Watanabe <fit0445 ＠ fitec.co.jp>
Subject: [pgsql-jp: 29901] ORACLEでいう DUAL 表は？
Date: Thu, 15 May 2003 15:53:01 +0900

;;; 　渡辺と申します。
;;; 
;;; 　ORACLE では DUAL という表があり
;;; 
;;; 　SELECT SYSDATE FROM DUAL ;
;;; 
;;; 　見たいに使っていましたが、postgresql では
;;; 　そのような表はあるのでしょうか？

  タプル数が 1 の表を作ってしまえばいいのではないでしょうか? DB2 でそうしてし
まいました。

  Oracle の DUAL は、

    =# SELECT now();

をしたいときに以下のように必ず FROM が必要なためにあると思っていました。

    =# SELECT now() FROM DUAL;

  他の使い方知らないので、教えて下さい。


Kenji Sugita                                      




From takanobu ＠ bananaware.net  Thu May 15 18:08:59 2003
From: takanobu ＠ bananaware.net (平山 貴信)
Date: Thu, 15 May 2003 18:08:59 +0900
Subject: [pgsql-jp: 29903] Re: ORACLEでいう DUAL 表は？
Message-ID: <46D52826F438364F99E6A6718CDBB359073093@server01.BananaDom.local>

平山と申します。

以下の件について私も以前にはまった覚えがありますねぇ、、、
（Oracleからの移行だったもんで、、、)

結果から言うとPostgresの場合はDUALに相当するものは
必要ありません。
そのまま
select current_timestamp
とかやれば取れます。

＃個人的にはどっちでもいいからSQLは全部統一してくれと思ってますけど、、、
 
> -----Original Message-----
> From: sugita ＠ sra.co.jp [mailto:sugita ＠ sra.co.jp]
> Sent: Thursday, May 15, 2003 3:59 PM
> To: pgsql-jp ＠ ml.postgresql.jp
> Subject: [pgsql-jp: 29902] Re: ORACLEでいう DUAL 表は？
> 
>   杉田です。
> 
> From: Hiroshi Watanabe <fit0445 ＠ fitec.co.jp>
> Subject: [pgsql-jp: 29901] ORACLEでいう DUAL 表は？
> Date: Thu, 15 May 2003 15:53:01 +0900
> 
> ;;; 　渡辺と申します。
> ;;;
> ;;; 　ORACLE では DUAL という表があり
> ;;;
> ;;; 　SELECT SYSDATE FROM DUAL ;
> ;;;
> ;;; 　見たいに使っていましたが、postgresql では
> ;;; 　そのような表はあるのでしょうか？
> 
>   タプル数が 1 の表を作ってしまえばいいのではないでしょうか? DB2 でそうし
> てし
> まいました。
> 
>   Oracle の DUAL は、
> 
>     =# SELECT now();
> 
> をしたいときに以下のように必ず FROM が必要なためにあると思っていました。
> 
>     =# SELECT now() FROM DUAL;
> 
>   他の使い方知らないので、教えて下さい。
> 
> 
> Kenji Sugita
> 



From ohr ＠ yoursys.org  Thu May 15 19:57:57 2003
From: ohr ＠ yoursys.org (ohara takaaki)
Date: Thu, 15 May 2003 19:57:57 +0900
Subject: [pgsql-jp: 29904] Re: pg_atoi エラーが出る
In-Reply-To: <20030515.145941.59650911.sugita@sra.co.jp>
References: <20030514233437.DA01.OHR@yoursys.org> <20030515.145941.59650911.sugita@sra.co.jp>
Message-ID: <20030515194949.6F7D.OHR@yoursys.org>

お世話になります．オハラです．

＞＞杉田さん

>   ログを採っていて、そのログを見る事ができれば可能です。
ログは全てみることができませんでした．

ブラウザ上に表示させた SQL をコピーして
同じように php から実行してみましたが，エラーは
出ませんでした．
カラムの順番を替えたりいろいろやっていますが，
解決しておりません（情けない＞＜）

＞＞望月さん

> $textCode = 'str010101954';
> $sql = "INSERT INTO table1(someflg, textCode) VALUES(0,'$textCode')";
> pg_exec($con, $sql);
> 
> で、pg_atoiのエラー がでるのは上記以外のカラムが実際は存在するのではない
> でしょうか？

ありがとうございます．
確認はしているのですが見落としているかもしれません．

実際のエラー表示と実際のテーブル構成を下記に：

# クエリ（表示させている）
INSERT INTO table1( 
dltflg, ordercode, payment, corporationid, sendflg, usercode,
productcode, itemnumber,discountamount,orderdate,description,
creditcardinfo,comment,price1)
VALUES (
0,'gwI1052993187','bank','1111111',0,1,7,1,0,'1052993187','','','',
'20000')

# エラー
Warning: pg_exec() query failed:
ERROR: pg_atoi: error in "gwI1052993187": can't parse "gwI1052993187" in
/home/my_home/public_html/***
line 238

同じ構成のテーブルに，上記クエリをコピペして php から INSERT 実行しても
エラーはありません（？？なぜだ？？）

# table1
 dltflg         | smallint |
 code           | integer  | not null default nextval('"table1_code_seq"'::text)
 ordercode      | text     |
 payment        | text     |
 corporationid  | text     |
 sendflg        | smallint |
 usercode       | bigint   |
 productcode    | bigint   |
 itemnumber     | integer  |
 discountamount | bigint   |
 orderdate      | text     |
 description    | text     |
 creditcardinfo | text     |
 comment        | text     |
 price1         | text     |
Unique keys: table1_code_key


-- 
ohara takaaki <ohr ＠ yoursys.org>



From yuin ＠ bb.din.or.jp  Thu May 15 20:41:12 2003
From: yuin ＠ bb.din.or.jp (Makoto,Yui)
Date: Thu, 15 May 2003 20:41:12 +0900
Subject: [pgsql-jp: 29905] Re: ORACLEでいう DUAL  表は？
In-Reply-To: <20030515.155921.38714150.sugita@sra.co.jp>
References: <20030515155118.9C87.FIT0445@fitec.co.jp>
	<20030515.155921.38714150.sugita@sra.co.jp>
Message-ID: <20030515204112.1d5e4f53.yuin@bb.din.or.jp>

油井です.

>   タプル数が 1 の表を作ってしまえばいいのではないでしょうか? DB2 でそうしてし
> まいました。

create view DUAL as
select null as DUAL;
#warningはでます.

select now() from DUAL;

でどうでしょう?
オラクルからのポーティングの為だけですけど, こうすれば
コード書き変えなくてもそのまま使えるかな..なんて.

って書き直したほうがいいですけど^^;

+-------------------------------------------------------------------+
Makoto Yui <yuin ＠ bb.din.or.jp>
Key fingerprint = 6462 E285 97D8 1323 40C4  F9E5 EB0F 9DE6 1713 219E
+-------------------------------------------------------------------+


From sugita ＠ sra.co.jp  Thu May 15 21:02:01 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Thu, 15 May 2003 21:02:01 +0900 (JST)
Subject: [pgsql-jp: 29906] Re: ORACLEでいう DUAL 表は？
In-Reply-To: <46D52826F438364F99E6A6718CDBB359073093@server01.BananaDom.local>
References: <46D52826F438364F99E6A6718CDBB359073093@server01.BananaDom.local>
Message-ID: <20030515.210201.74753167.sugita@sra.co.jp>

From: 平山 貴信 <takanobu ＠ bananaware.net>
Subject: [pgsql-jp: 29903] Re: ORACLEでいう DUAL 表は？
Date: Thu, 15 May 2003 18:08:59 +0900

;;; ＃個人的にはどっちでもいいからSQLは全部統一してくれと思ってますけど、、、

  言語的には、SQL 自体が出鱈目なので、全て捨てて、根本的にまともにしたほうがい
いです。あんなのは、まっとうな、コンピュータ言語ではありません。


Kenji Sugita                                      



From sugita ＠ sra.co.jp  Thu May 15 21:10:17 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Thu, 15 May 2003 21:10:17 +0900 (JST)
Subject: [pgsql-jp: 29907] Re: ORACLEでいう DUAL 表は？
In-Reply-To: <20030515204112.1d5e4f53.yuin@bb.din.or.jp>
References: <20030515155118.9C87.FIT0445@fitec.co.jp>
	<20030515.155921.38714150.sugita@sra.co.jp>
	<20030515204112.1d5e4f53.yuin@bb.din.or.jp>
Message-ID: <20030515.211017.41633718.sugita@sra.co.jp>

From: "Makoto,Yui" <yuin ＠ bb.din.or.jp>
Subject: [pgsql-jp: 29905] Re: ORACLEでいう DUAL 表は？
Date: Thu, 15 May 2003 20:41:12 +0900

;;; >   タプル数が 1 の表を作ってしまえばいいのではないでしょうか? DB2 でそうしてし
;;; > まいました。
;;; 
;;; create view DUAL as
;;; select null as DUAL;
;;; #warningはでます.
;;; 
;;; select now() from DUAL;
;;; 
;;; でどうでしょう?
;;; オラクルからのポーティングの為だけですけど, こうすれば
;;; コード書き変えなくてもそのまま使えるかな..なんて.
;;; 
;;; って書き直したほうがいいですけど^^;

  DUAL なんてのを用意することが、上記以上の意味を持たないならば、Oracle の言語
仕様上のバグです。 


Kenji Sugita                                      
    


From hara ＠ quest.co.jp  Thu May 15 21:25:28 2003
From: hara ＠ quest.co.jp (原　啓次)
Date: Thu, 15 May 2003 21:25:28 +0900
Subject: [pgsql-jp: 29908] NOW()関数のJDBC経由時の動作について
Message-ID: <20030515211017.2CC6.HARA@quest.co.jp>

お世話になります。
原と申します。

環境
Redhat 7.3
PostgreSQL 7.3.2
Apache 1.3.27
JDK 1.3.07
Tomcat 4.1.24

上記環境でServletによる開発を行っております。
INSERT時にPostgreSQLのNOW()という関数を利用しています。
この関数は同一トランザクションでは何回SELECTしても同じ時刻を示すとありました。
そこで、クライアントからpsqlを利用し、beginでトランザクションを開始後に
SELECT NOW();を複数回実行しました。
結果として同じ時刻を抽出していました。
これは納得したのですが、ServletでWebより実行したケースでは、
commitを発行してトランザクションを複数発生させているにもかかわらず
現在時刻より30分以上前の値を持ってきていました。
トランザクションのほかに、JDBCのコネクションなど何か原因があるのでしょう
か？

もしなにかありましたら、教えていただけますようよろしくお願いします。


以上です。

原　啓次 hara ＠ quest.co.jp




From mochizuki ＠ adcoop.co.jp  Thu May 15 21:36:29 2003
From: mochizuki ＠ adcoop.co.jp (Takashi Mochizuki)
Date: Thu, 15 May 2003 21:36:29 +0900
Subject: [pgsql-jp: 29909] Re: pg_atoi エラーが出る
In-Reply-To: <20030515194949.6F7D.OHR@yoursys.org>
References: <20030515.145941.59650911.sugita@sra.co.jp> <20030515194949.6F7D.OHR@yoursys.org>
Message-ID: <20030515212201.3AFC.MOCHIZUKI@adcoop.co.jp>

望月です。

試しに、同じテーブル(テーブル名はhogeですが)
でPHP(長くなるのでソースは記載しませんが)
からやってみましたが、ERROR: pg_atoi: にはなりませんでした。

>同じ構成のテーブルに，上記クエリをコピペして php から INSERT 実行しても
>エラーはありません（？？なぜだ？？）

ということは、実際のスクリプトでは 
dltflg
が空になっているので 
ordercode
がずれて、挿入されている可能性があるのではないでしょうか？
想像ですが、というか失礼ですが name と value の値があっていないとか・・
・


From ohr ＠ yoursys.org  Thu May 15 21:57:22 2003
From: ohr ＠ yoursys.org (ohara takaaki)
Date: Thu, 15 May 2003 21:57:22 +0900
Subject: [pgsql-jp: 29910] Re: pg_atoi エラーが出る
In-Reply-To: <20030515212201.3AFC.MOCHIZUKI@adcoop.co.jp>
References: <20030515194949.6F7D.OHR@yoursys.org> <20030515212201.3AFC.MOCHIZUKI@adcoop.co.jp>
Message-ID: <20030515215517.6F7F.OHR@yoursys.org>

オハラです．

付き合っていただいてありがとうございます．

> ということは、実際のスクリプトでは 
> dltflg
> が空になっているので 
> ordercode
> がずれて、挿入されている可能性があるのではないでしょうか？
> 想像ですが、というか失礼ですが name と value の値があっていないとか・・

かもしれません．もう一度，じっくり見直していきます．
お手数かけます．

-- 
ohara takaaki <ohr ＠ yoursys.org>



From sugita ＠ sra.co.jp  Thu May 15 22:05:52 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Thu, 15 May 2003 22:05:52 +0900 (JST)
Subject: [pgsql-jp: 29911] Re: NOW()関数のJDBC 経由時の動作について
In-Reply-To: <20030515211017.2CC6.HARA@quest.co.jp>
References: <20030515211017.2CC6.HARA@quest.co.jp>
Message-ID: <20030515.220552.71088354.sugita@sra.co.jp>

  杉田です。

From: 原　啓次 <hara ＠ quest.co.jp>
Subject: [pgsql-jp: 29908] NOW()関数のJDBC 経由時の動作について
Date: Thu, 15 May 2003 21:25:28 +0900

;;; 環境
;;; Redhat 7.3
;;; PostgreSQL 7.3.2
;;; Apache 1.3.27
;;; JDK 1.3.07
;;; Tomcat 4.1.24
;;; 
;;; 上記環境でServletによる開発を行っております。
;;; INSERT時にPostgreSQLのNOW()という関数を利用しています。
;;; この関数は同一トランザクションでは何回SELECTしても同じ時刻を示すとありました。
;;; そこで、クライアントからpsqlを利用し、beginでトランザクションを開始後に
;;; SELECT NOW();を複数回実行しました。
;;; 結果として同じ時刻を抽出していました。
;;; これは納得したのですが、ServletでWebより実行したケースでは、
;;; commitを発行してトランザクションを複数発生させているにもかかわらず
;;; 現在時刻より30分以上前の値を持ってきていました。
;;; トランザクションのほかに、JDBCのコネクションなど何か原因があるのでしょう
;;; か？

  アプリケーション側のミスの可能性がかなり高いです。全クエリーをサーバ側でモニ
ターし、かつアプリケーション側のクエリーと処理を見直すのが先決と思えます。


Kenji Sugita                                      



From hotaka ＠ sk.tsukuba.ac.jp  Thu May 15 22:13:46 2003
From: hotaka ＠ sk.tsukuba.ac.jp (R. Hotaka)
Date: Thu, 15 May 2003 22:13:46 +0900
Subject: [pgsql-jp: 29912] Re: ORACLE でいう DUAL 表は？
In-Reply-To: <20030515.210201.74753167.sugita@sra.co.jp>
References: <46D52826F438364F99E6A6718CDBB359073093@server01.BananaDom.local>
 <46D52826F438364F99E6A6718CDBB359073093@server01.BananaDom.local>
Message-ID: <4.2.0.58.J.20030515221001.01fce2b8@smtp01.itscom.net>

穗鷹です．

At 03/05/15 21:02, you wrote:
>From: 平山 貴信 <takanobu ＠ bananaware.net>
>Subject: [pgsql-jp: 29903] Re: ORACLEでいう DUAL 表は？
>Date: Thu, 15 May 2003 18:08:59 +0900
>
>;;; ＃個人的にはどっちでもいいからSQLは全部統一してくれと思ってますけど、、、
>
>   言語的には、SQL 
> 自体が出鱈目なので、全て捨てて、根本的にまともにしたほうがい
>いです。あんなのは、まっとうな、コンピュータ言語ではありません。
>
>
>Kenji Sugita

同感です．昔のスペックは非常に分かりやすかったのですが，商業的に成功したので 
教育で一儲けしようというベンダの思惑でどんどん複雑になっているのだと思います． 
利用者は十分賢くなって不要なスペックの製品は使用しないようにしない限りこの傾 
向は止められませんね．


From yohgaki ＠ ohgaki.net  Thu May 15 23:52:30 2003
From: yohgaki ＠ ohgaki.net (Yasuo Ohgaki)
Date: Thu, 15 May 2003 23:52:30 +0900
Subject: [pgsql-jp: 29913] Re: ORACLE でいう DUAL  表は？
References: <46D52826F438364F99E6A6718CDBB359073093@server01.BananaDom.local> <46D52826F438364F99E6A6718CDBB359073093@server01.BananaDom.local> <4.2.0.58.J.20030515221001.01fce2b8@smtp01.itscom.net>
Message-ID: <3EC3A9AE.40804@ohgaki.net>

大垣です。

R. Hotaka wrote:
> 同感です．昔のスペックは非常に分かりやすかったのですが，商業的に成功したので 
> 教育で一儲けしようというベンダの思惑でどんどん複雑になっているのだと思います． 
> 利用者は十分賢くなって不要なスペックの製品は使用しないようにしない限りこの傾 
> 向は止められませんね．
> 

不必要なベンダー拡張には危ない物も沢山あり、しかもデフォルトで
利用できるようになっていたりします（某社DBのxp_* 等）...中途半端
な設定とアプリケーションの作りだとユーザーが想像する以上のダメージ
をシステムに与えかねないので、不要なスペックを多く持つ製品をどう
しても使わなければならない場合は不要なスペックを無効にするのは重
要と思います。

# 穗鷹先生、お久しぶりです。
# 田中耕一さんの受賞の際にインタビュー（確かNHK）に出られていた
# ので驚きました。

--
Yasuo Ohgaki






From ohr ＠ yoursys.org  Fri May 16 01:51:29 2003
From: ohr ＠ yoursys.org (ohara takaaki)
Date: Fri, 16 May 2003 01:51:29 +0900
Subject: [pgsql-jp: 29914] Re: pg_atoi エラーが出る
In-Reply-To: <20030515215517.6F7F.OHR@yoursys.org>
References: <20030515212201.3AFC.MOCHIZUKI@adcoop.co.jp> <20030515215517.6F7F.OHR@yoursys.org>
Message-ID: <20030516014921.AA9B.OHR@yoursys.org>

オハラです：

やっぱりというか，おはずかしいことに，
たんなる「チョンボ」でした．

目をつけていた関数ではなくて別の関数で
作成された sql の insert でエラーが出ていました．
テーブルも別のテーブルでした＞＜；
（目をつけていたテーブルには正常にデータが
挿入されているのを知っていたのに・・・）

その sql の対象のテーブルが誤って作成されており，
そのテーブルを修正すればOKでした．

# アドヴァイスしてくださった方々，大変申し訳ありませんでした．
# 的外れも甚だしい！ すみませんでした！　＞＞望月さん

人の書いたソースを追っているので，またこのような
ことで投稿するかもしれませんが，その時は懲りずに
よろしくお願いします．
-- 
ohara takaaki <ohr ＠ yoursys.org>



From mae ＠ itc-net.co.jp  Fri May 16 09:11:42 2003
From: mae ＠ itc-net.co.jp (前　宏尚)
Date: Fri, 16 May 2003 09:11:42 +0900
Subject: [pgsql-jp: 29915] Re: EXEやバッチの起動について
In-Reply-To: <20030510.225449.85411946.t-ishii@sra.co.jp>
References: <20030510.225449.85411946.t-ishii@sra.co.jp>
Message-ID: <200305160020.JAA06504@ns.itc-net.co.jp>

石井様。

> > ＥＸＥやバッチを、PL/pgSQLの中で実行させる方法
> > （Unix上で動作させる為、できればshellを実行させる方法）
> > を探しているのですが、いろいろなサイト、ドキュメント等を見ても、
> > それらしきものが載っておらず（読解力がないだけかもしれませんが）、
> > ご存知の方がおられましたら、どうかお知恵をお貸しいただけないでしょうか？
> > よろしくお願いいたします。
> 
> PL/shというのがあります．その名の通り，shell scriptでユーザ定義関数を
> 書けるものです．
> 
> http://www.ca.postgresql.org/~petere/plsh.html
> 
> 言うまでもありませんが，使い方によってはもろにセキュリティホールになる
> ので，気をつけましょう．

ご指摘ありがとうございます。

⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔
前　<mae ＠ itc-net.co.jp>
⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔⇔



From no ＠ kasas.org  Fri May 16 13:38:21 2003
From: no ＠ kasas.org (KASAHARA Norio)
Date: Fri, 16 May 2003 13:38:21 +0900
Subject: [pgsql-jp: 29916] Re: ORACLEでいう DUAL  表は？
In-Reply-To: <20030515.211017.41633718.sugita@sra.co.jp>
Message-ID: <3955AB48-8758-11D7-A550-0003939D0DE6@kasas.org>

かさはらと言います。こんにちは。

On 2003.5.15, at 21:10 Japan, sugita ＠ sra.co.jp wrote:
>   DUAL なんてのを用意することが、上記以上の意味を持たないならば、Oracle の言語
> 仕様上のバグです。

あえて刺激的な表現をされているのだと思いますが、あまりに乱暴なので、少しコメン
トさせてください。
仕様にバグなんてものはありません。その仕様がリーズナブルなものかどうかはともか
く、どんな仕様にしようがそれはベンダーの自由です。その仕様が良いものであれば
いずれANSI/ISOなど標準に取り入れられて行くでしょう。

PostgreSQLのリファレンスマニュアルを見ていただければ分かりますが、SELECT文
でFROM句を省略できるのは、PostgreSQLの独自仕様です。
FROM句を常に必要とするOracleの方がANSI/ISO SQLに忠実だと言えるでしょう。

Oracleで
　　　　SELECT * FROM DUAL;
としてみれば分かりますが、DUALは１行１列の小さなテーブルです。DUALという
のは特殊なデータベースオブジェクトでも何でもありません。

同じことを実現するために、SQLを独自拡張しているPostgreSQLと、そうでない
Oracleとどっちの仕様がバグっているのでしょうね。
（もちろん、どっちの仕様もバグっていません）
--
カさはらのりお     no ＠ kasas.org



From sugita ＠ sra.co.jp  Fri May 16 13:44:27 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Fri, 16 May 2003 13:44:27 +0900 (JST)
Subject: [pgsql-jp: 29917] Re: ORACLEでいう DUAL 表は？
In-Reply-To: <3955AB48-8758-11D7-A550-0003939D0DE6@kasas.org>
References: <20030515.211017.41633718.sugita@sra.co.jp>
	<3955AB48-8758-11D7-A550-0003939D0DE6@kasas.org>
Message-ID: <20030516.134427.59678315.sugita@sra.co.jp>

  杉田です。

From: KASAHARA Norio <no ＠ kasas.org>
Subject: [pgsql-jp: 29916] Re: ORACLEでいう DUAL 表は？
Date: Fri, 16 May 2003 13:38:21 +0900

;;; Oracleで
;;; 　　　　SELECT * FROM DUAL;
;;; としてみれば分かりますが、DUALは１行１列の小さなテーブルです。DUALという
;;; のは特殊なデータベースオブジェクトでも何でもありません。
&
;;; 同じことを実現するために、SQLを独自拡張しているPostgreSQLと、そうでない
;;; Oracleとどっちの仕様がバグっているのでしょうね。
;;; （もちろん、どっちの仕様もバグっていません）

  そういう表を取り入れるのがとても汚く、そう考えようとする事自体が間違いと思え
ます。それよりも FROM を不用なように独自拡張する方がよい方法です。


Kenji Sugita                                      



From hyoshiok ＠ miraclelinux.com  Fri May 16 14:20:54 2003
From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka)
Date: Fri, 16 May 2003 14:20:54 +0900
Subject: [pgsql-jp: 29918] Re: ORACLEでいう DUAL 表は？
In-Reply-To: <20030516.134427.59678315.sugita@sra.co.jp>
References: <20030515.211017.41633718.sugita@sra.co.jp>
	<3955AB48-8758-11D7-A550-0003939D0DE6@kasas.org>
	<20030516.134427.59678315.sugita@sra.co.jp>
Message-ID: <20030516142054W.hyoshiok@miraclelinux.com>

よしおかです。

>   杉田です。

こんにちは、

言語の設計というのは興味がつきない話題なのですが、

>   そういう表を取り入れるのがとても汚く、そう考えようとする事自体が間違いと思え
> ます。それよりも FROM を不用なように独自拡張する方がよい方法です。

言語のシンタックスに例外をあたえるのか(fromがある場合とない場合)、
それともあたえないのか(常にfromを要求する)がいいのか、
そういう表をいれるのが、いいのかわるいのか。

ところで、そう考えようとするのが間違いとのことなのですが、
何が間違いなのか、教えてください。

わたしには、どっちもどっち、五十歩百歩のような気がしています。

よ
--
Hiro Yoshioka/CTO, Miracle Linux
mailto:hyoshiok ＠ miraclelinux.com
http://www.miraclelinux.com
今月の目標：バグフィックス


From sugita ＠ sra.co.jp  Fri May 16 14:37:55 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Fri, 16 May 2003 14:37:55 +0900 (JST)
Subject: [pgsql-jp: 29919] Re: ORACLEでいう DUAL 表は？
In-Reply-To: <20030516142054W.hyoshiok@miraclelinux.com>
References: <3955AB48-8758-11D7-A550-0003939D0DE6@kasas.org>
	<20030516.134427.59678315.sugita@sra.co.jp>
	<20030516142054W.hyoshiok@miraclelinux.com>
Message-ID: <20030516.143755.28812151.sugita@sra.co.jp>

  杉田です。

From: Hiro Yoshioka <hyoshiok ＠ miraclelinux.com>
Subject: [pgsql-jp: 29918] Re: ORACLEでいう DUAL 表は？
Date: Fri, 16 May 2003 14:20:54 +0900

;;; ところで、そう考えようとするのが間違いとのことなのですが、
;;; 何が間違いなのか、教えてください。

  汚いオブジェクトが脈絡もなく存在するからです。

;;; わたしには、どっちもどっち、五十歩百歩のような気がしています。

  私は、そうは感じません。


Kenji Sugita                                      



From hikeda ＠ miraclelinux.com  Fri May 16 14:50:25 2003
From: hikeda ＠ miraclelinux.com (池田　秀一)
Date: Fri, 16 May 2003 14:50:25 +0900
Subject: [pgsql-jp: 29920] Re: ORACLEでいう DUAL 表は？
In-Reply-To: <20030516.134427.59678315.sugita@sra.co.jp>
References: <3955AB48-8758-11D7-A550-0003939D0DE6@kasas.org> <20030516.134427.59678315.sugita@sra.co.jp>
Message-ID: <20030516144642.CDCE.HIKEDA@miraclelinux.com>

池田です。

> ;;; 同じことを実現するために、SQLを独自拡張しているPostgreSQLと、そうでない
> ;;; Oracleとどっちの仕様がバグっているのでしょうね。
> ;;; （もちろん、どっちの仕様もバグっていません）
> 
>   そういう表を取り入れるのがとても汚く、そう考えようとする事自体が間違いと思え
> ます。それよりも FROM を不用なように独自拡張する方がよい方法です。

　『どっちもどっち』でしょうねぇ。どちらも「よい方法」とは
言いきれないでしょう。言いきれるのが疑問です。

　データベース製品ごとの方言で、どちらが良いとは一概に言え
ませんよ。『慣れ』の問題がほとんどだと考えますね。

# バグだと考えるのであれば、SRA さんは Oracle の代理店なの
# ですから、バグとして申請するのも良いかもしれません。

ではでは。
-- -- -- -- -- -- -- -- 
池田　秀一 <ikeda ＠ miraclelinux.com>    Hidekazu Ikeda  
 Sales Division, Business Development,  Director 
　TEL: 03-5562-8310  Fax: 03-5562-8306 
----------  
Oracle9i Database Linux版キャンペーン　 2003/9/30迄
--★MIRACLE LINUX お知らせ★-----------------------
申┃込┃受┃付┃中┃MIRACLE LINUX プロダクトサポート
━┛━┛━┛━┛━┛〜品質向上計画　発動中！！〜　　
http://www.miraclelinux.co.jp/support/product.html
----------------------------------------------------------------------



From fit0445 ＠ fitec.co.jp  Fri May 16 15:18:19 2003
From: fit0445 ＠ fitec.co.jp (Hiroshi Watanabe)
Date: Fri, 16 May 2003 15:18:19 +0900
Subject: [pgsql-jp: 29921] postgres7.3.2 JDBC経由のデータが文字化け
Message-ID: <20030516150441.7759.FIT0445@fitec.co.jp>

　渡辺と申します。

RedHat Linux
postgresql 7.3.2
JDK 1.2.2-015
ANT 1.4.3-1

以上を使って

postgresql を

$ ./configure --enable-multibyte=EUC_JP --enable-syslog --with-java
$ make all
$ make install
$ cd src/interface/jdbc
$ make
$ make install

として、作成されたjarファイルに CLASSPATH を設定し、JDBC経由で
データの入出力を行ったところ、漢字(2バイト文字)について

psql , ODBC 経由で登録したデータ
　↓
それらの環境では見れるが、JDBCでは文字化け


JDBC経由で登録したデータ
　↓
それらの環境では見れるが、psql ODBC では文字化け

となってしまいます。

ちなみに、pg_dump で中身を見たところ、JDBC で登録したデータは
正常に見られませんでした。(EUC環境で)

いろいろ調べて、initdb の際に --locale-no オプションを指定しても
みたのですが、状況は変わりませんでした。原因について何か心当たり
ある方は是非教えてください。





From snaga ＠ snaga.org  Fri May 16 15:20:19 2003
From: snaga ＠ snaga.org (Satoshi Nagayasu)
Date: Fri, 16 May 2003 15:20:19 +0900
Subject: [pgsql-jp: 29922] Re: ORACLEでいう DUAL  表は？
In-Reply-To: <20030516144642.CDCE.HIKEDA@miraclelinux.com>
References: <3955AB48-8758-11D7-A550-0003939D0DE6@kasas.org>
	<20030516.134427.59678315.sugita@sra.co.jp>
	<20030516144642.CDCE.HIKEDA@miraclelinux.com>
Message-ID: <20030516152019.42c3b7b0.snaga@snaga.org>

永安です。

Oracle知らないのに横からすみません。この話はときどき聞くので便乗です。

# 「仕様に沿っていれば正しい」というのは、正しさの「一面」であって、
# 意味的な正しさとは一致しない、しかし意味的な正しさが常に要求される
# わけでもない、というのが私のスタンスです。

池田　秀一 <hikeda ＠ miraclelinux.com> wrote:
> >   そういう表を取り入れるのがとても汚く、そう考えようとする事自体が間違いと思え
> > ます。それよりも FROM を不用なように独自拡張する方がよい方法です。
> 
> 　『どっちもどっち』でしょうねぇ。どちらも「よい方法」とは
> 言いきれないでしょう。言いきれるのが疑問です。
> 
> 　データベース製品ごとの方言で、どちらが良いとは一概に言え
> ませんよ。『慣れ』の問題がほとんどだと考えますね。

「慣れの問題」と言ってしまえば、それは間違いなくその通りだと思うのですが、
まぁそれは置いておくとして、聞く限りにおいて、

 - なぜ DUAL という名前なのか？
 - そもそも、なぜ必要なのか

がよく分かりません。

つまり、どういう必然性があってそうなっているのかが、理解しづらいんだと思
います。PostgreSQLでは存在していないわけですし、私自身も DUAL なるものが
存在している必然性がよく理解できてません。

# 「脈絡のないオブジェクト」という指摘は、それはそれで正しいと感じています（私は）。

 - 意味が先にあって、意味に文法を合わせるのか（FROM DUALが不要）
 - 文法が先にあって、文法に意味を合わせるのか（常にFROM句が必要）

の違いじゃないでしょうか。

「SQLの仕様に忠実だから正しい」というのは、そのレイヤーを見ればその通り
かもしれませんが、「そもそもSQLがなぜそういう仕様になっているのか」とい
うSQLの仕様自体が意味的に正しいかどうかとは別でしょう。

だからこそ、

> FROM句を常に必要とするOracleの方がANSI/ISO SQLに忠実

という指摘に対して、杉田さんの

> 言語的には、SQL 自体が出鱈目

という話になるんじゃないでしょうか。

「SQL仕様に沿っているから正しい」という主張と「SQL仕様自体が間違っている」
という議論が噛み合うわけがないと思うのですが（論理的に）。どのレイヤーに
フォーカスして「正しい」と言うのかによって、認識は変わってくると思います。

エンジニア的には、「別に使えりゃいいじゃん」ということなのかもしれません
し、確かにそういう結論でも構わないとは思いますが。

ちなみに「仕様にバグなんてものはありません」ということはありません。
論理的なバグが入り込む余地はいくらでもあります。

-- 
NAGAYASU Satoshi <snaga ＠ snaga.org>


From sirius ＠ jp.fujitsu.com  Fri May 16 15:24:06 2003
From: sirius ＠ jp.fujitsu.com (Takao Kato)
Date: Fri, 16 May 2003 15:24:06 +0900
Subject: [pgsql-jp: 29923] Re: postgres7.3.2 JDBC経由のデータが文字化け
In-Reply-To: <20030516150441.7759.FIT0445@fitec.co.jp>
References: <20030516150441.7759.FIT0445@fitec.co.jp>
Message-ID: <u33cjf8l4p.wl@lespaul.lantc.cs.fujitsu.co.jp>

 加藤＠川崎です。

はずしていたらごめんなさい。

> postgresql 7.3.2
> $ ./configure --enable-multibyte=EUC_JP --enable-syslog --with-java

..snip..

> ちなみに、pg_dump で中身を見たところ、JDBC で登録したデータは
> 正常に見られませんでした。(EUC環境で)
> 
> いろいろ調べて、initdb の際に --locale-no オプションを指定しても
> みたのですが、状況は変わりませんでした。原因について何か心当たり
> ある方は是非教えてください。


7.3から configure 時の --enable-mutltibye は意味をなしません。
# --enable-syslog も(ただしこっちはデフォルト)

ですから、

  $ initdb --no-locale --encoding=EUC_JP

を指定してあげれば良いかと思います。

では
----
加藤＠川崎
お便りは kato ＠ lantc.cs.fujitsu.co.jp まで


From fit0445 ＠ fitec.co.jp  Fri May 16 15:54:05 2003
From: fit0445 ＠ fitec.co.jp (Hiroshi Watanabe)
Date: Fri, 16 May 2003 15:54:05 +0900
Subject: [pgsql-jp: 29924] Re: postgres7.3.2 JDBC経由のデータが文字化け
In-Reply-To: <u33cjf8l4p.wl@lespaul.lantc.cs.fujitsu.co.jp>
References: <20030516150441.7759.FIT0445@fitec.co.jp> <u33cjf8l4p.wl@lespaul.lantc.cs.fujitsu.co.jp>
Message-ID: <20030516155140.775C.FIT0445@fitec.co.jp>

　渡辺です

　ありがとうございます。下記の方法でうまくいきました。
　psql -l で見てみたら、 Encodingが SQL_ASCII になってました。

> 7.3から configure 時の --enable-mutltibye は意味をなしません。
> # --enable-syslog も(ただしこっちはデフォルト)
> 
> ですから、
> 
>   $ initdb --no-locale --encoding=EUC_JP
> 
> を指定してあげれば良いかと思います。






From hikeda ＠ miraclelinux.com  Fri May 16 16:05:28 2003
From: hikeda ＠ miraclelinux.com (池田　秀一)
Date: Fri, 16 May 2003 16:05:28 +0900
Subject: [pgsql-jp: 29925] Re: ORACLEでいう DUAL 表は？
In-Reply-To: <20030516152019.42c3b7b0.snaga@snaga.org>
References: <20030516144642.CDCE.HIKEDA@miraclelinux.com> <20030516152019.42c3b7b0.snaga@snaga.org>
Message-ID: <20030516152939.CDD6.HIKEDA@miraclelinux.com>

池田です。

>  - なぜ DUAL という名前なのか？
>  - そもそも、なぜ必要なのか
> 
> がよく分かりません。

　すいません、俺も命名基準は知りません。また、まったく興味も
ありません。たぶん、From 句で対応したかったのかなと類推する
のはできますが。。
　で、その命名基準が判れば、納得できるとも思えませんが。。

> つまり、どういう必然性があってそうなっているのかが、理解しづらいんだと思
> います。PostgreSQLでは存在していないわけですし、私自身も DUAL なるものが
> 存在している必然性がよく理解できてません。

　繰り返すけど、どっちもどっちでしょう。

　私は、汎用機上のデータベース(NEC ADBS,RIQS-II）、TeraData、
BritonLee、Sybase、Oracle、SQL Server などに関わってきました
が、その経験（慣れ）から『Select 文に From が無い方が非常に
気持ち悪い』です。で、実装理由を聞いても、感覚の問題だから
気持ちが悪いと言う個人の主観、感覚は変わらないですね。
 
> # 「脈絡のないオブジェクト」という指摘は、それはそれで正しいと感じています（私は）。
> 
>  - 意味が先にあって、意味に文法を合わせるのか（FROM DUALが不要）
>  - 文法が先にあって、文法に意味を合わせるのか（常にFROM句が必要）
> 
> の違いじゃないでしょうか。

その通りです。で、脈絡のない気持ち悪い点が、オブジェクトの
存在なのか？、From 句が無いのか？、の差でしかありません。

> 「SQLの仕様に忠実だから正しい」というのは、そのレイヤーを見ればその通り
> かもしれませんが、「そもそもSQLがなぜそういう仕様になっているのか」とい
> うSQLの仕様自体が意味的に正しいかどうかとは別でしょう。

逆に問います。では何を持って「正しいか」を議論したいのですか？

SQL仕様を基盤に話さないのであれば、感覚論に終始して意味が無い
と考えます。他に基盤にできるモノがありますか？

> > FROM句を常に必要とするOracleの方がANSI/ISO SQLに忠実
> 
> という指摘に対して、杉田さんの
> 
> > 言語的には、SQL 自体が出鱈目
> 
> という話になるんじゃないでしょうか。

SQL 自体が拡張の繰り返しなのは事実ですが、RDBMS 出現する以前
の「SQL仕様も存在しない状況」に比較すれば百倍マシです。
SQL仕様にも多少問題があるとは思いますが、無視して進めるのが
良いとはまったく考えません。
 
> 「SQL仕様に沿っているから正しい」という主張と「SQL仕様自体が間違っている」
> という議論が噛み合うわけがないと思うのですが（論理的に）。どのレイヤーに
> フォーカスして「正しい」と言うのかによって、認識は変わってくると思います。

「SQL仕様がおかしい」と主張するのは自由ですが、様々な標準化
の中でも上手く行っているほうだと捉えます。ですので、SQL仕様
と異なる独自拡張仕様を各社が独自に広げるのは良い事とは逆に
考えません。独自拡張は必要悪であり、積極的に行うべきことで
はありません。
逆に、本当に SQL仕様が間違っていると考えるのであれば、独自
実装の DBMS を作成するよりも、SQL仕様を変えるように行動する
方が正しい行動に考えますね。
 
> エンジニア的には、「別に使えりゃいいじゃん」ということなのかもしれません

違います「顧客的には」です。エンジニア的には、別の視点もある
かとは思います。

> ちなみに「仕様にバグなんてものはありません」ということはありません。

「仕様バグ」と言うのは、個別開発では明確に言い易いですが、
不特定多数の顧客から利用されている製品において、顧客ごとに
判断が異なる場合には、一概に「仕様バク」とは言えません。

特定の顧客要望で、仕様バグとして対応した場合に、他の顧客と
しては新規の仕様バグとして認識される可能性があります。

顧客から見れば、SJIS で DB が作成できないのも仕様バグだと
考える人も居るかもしれません。

> 論理的なバグが入り込む余地はいくらでもあります。

繰り返しますが、「仕様バク」だと考えるのであれば、提供元に
伝えるのが「技術者としては誠実な行動」ではありませんか？
って書いてる訳です。

私はバグだと捉えてませんので、連絡はしませんが。。

ではでは。
-- -- -- -- -- -- -- -- 
池田　秀一 <ikeda ＠ miraclelinux.com>    Hidekazu Ikeda  
 Sales Division, Business Development,  Director 
　TEL: 03-5562-8310  Fax: 03-5562-8306 
----------  
Oracle9i Database Linux版キャンペーン　 2003/9/30迄
--★MIRACLE LINUX お知らせ★-----------------------
申┃込┃受┃付┃中┃MIRACLE LINUX プロダクトサポート
━┛━┛━┛━┛━┛〜品質向上計画　発動中！！〜　　
http://www.miraclelinux.co.jp/support/product.html
----------------------------------------------------------------------



From no ＠ kasas.org  Fri May 16 16:09:09 2003
From: no ＠ kasas.org (KASAHARA Norio)
Date: Fri, 16 May 2003 16:09:09 +0900
Subject: [pgsql-jp: 29926] Re: ORACLEでいう DUAL   表は？
In-Reply-To: <20030516152019.42c3b7b0.snaga@snaga.org>
Message-ID: <4A3F8650-876D-11D7-A550-0003939D0DE6@kasas.org>

かさはらです。こんにちは。

On 2003.5.16, at 15:20 Japan, Satoshi Nagayasu wrote:

> つまり、どういう必然性があってそうなっているのかが、理解しづらいんだと思
> います。PostgreSQLでは存在していないわけですし、私自身も DUAL なるものが
> 存在している必然性がよく理解できてません。
>
今回のケースでもそうですが、DUAL表はシステムデイトを取って来るときによく
使われます。で、システムデイトを取って来るのに、なんでSELECT文なの？とい
うところからおかしくなっている訳です。
ANSI/ISO SQLでは、SELECT文は、テーブル/ビューに代数演算を加えた結果を
取得するための文であるはずです。それを想定されていない目的に流用しようとす
るからムリが来るんだと思います。
テーブルを参照しないSELECT文自体がSQLをまげて解釈していると思えます。
その点では、PostgreSQLもダミーの表を使うOracleも同じです。

>  - 意味が先にあって、意味に文法を合わせるのか（FROM DUALが不要）
>  - 文法が先にあって、文法に意味を合わせるのか（常にFROM句が必要）
>
意味を考えるのなら、なぜSELECT文を使うのかというところから考えるべきで
しょう。
サーバの時計を参照したいのなら、他の方法があります。既にSQLに問い合わせ
言語以上のものを求めているのですから、それは、ホスト言語側に任せるか、
PSL/PSM(PostgreSQLでのPLpg/SQL)などのSQLのモジュール言語拡張機能
を利用すればいいのではないですか？

> 「SQLの仕様に忠実だから正しい」というのは、そのレイヤーを見ればその通り
> かもしれませんが、「そもそもSQLがなぜそういう仕様になっているのか」とい
> うSQLの仕様自体が意味的に正しいかどうかとは別でしょう。
>
「正しい」という言葉の定義をしなければならないのですが、仕様はあるもので
あって、その仕様が、自分のやろうとしていることに都合が良いか悪いかはとい
う判断はあっても、正しい/正しくないという判断はないというのが私の考えで
す。
ユークリッド幾何学と非ユークリッド幾何学のどちらが正しいのかという議論を
してもしようがなくて、自分がやろうとしていることは、どちらをベースにすれ
ば都合が良いかだと思います。
「関数に与える引数を間違えると、コンピュータシステムが爆発することがあり
ます」という仕様のシステムがあっても、その仕様は間違っている訳ではなく、
自分の仕事では、それでは困るのであれば、使わなければいいだけです。

> 「SQL仕様に沿っているから正しい」という主張と「SQL仕様自体が間違っている」
> という議論が噛み合うわけがないと思うのですが（論理的に）。どのレイヤーに
> フォーカスして「正しい」と言うのかによって、認識は変わってくると思います。
>
「SQLが間違っている」というのなら、SQLを使わなければいいと思います。
そういうオールオアナッシングの議論をするな、というのなら、各論をしますが、
今回は、OracleからPostgreSQLへポーティングで問題が発生していますから、
であれば、移植性を問題にするべきですよね。
この「レイヤー」に関して言えば、移植性が高いものが「正しく」、低いものが
「正しくない」。
注意してほしいのは、文法が標準に忠実だから移植性が高いと言うつもりはない
ということです。ポータビリティの議論をするならしましょう。
ただ、その場合は、「訳の分からないオブジェクトがあって汚い」というのは
正しい/正しくないということに直接的に関係ないという前提で話をしましょう。

--
カさはらのりお     no ＠ kasas.org



From snaga ＠ snaga.org  Fri May 16 16:33:41 2003
From: snaga ＠ snaga.org (Satoshi Nagayasu)
Date: Fri, 16 May 2003 16:33:41 +0900
Subject: [pgsql-jp: 29927] Re: ORACLEでいう DUAL  表は？
In-Reply-To: <20030516152939.CDD6.HIKEDA@miraclelinux.com>
References: <20030516144642.CDCE.HIKEDA@miraclelinux.com>
	<20030516152019.42c3b7b0.snaga@snaga.org>
	<20030516152939.CDD6.HIKEDA@miraclelinux.com>
Message-ID: <20030516163341.58c9534e.snaga@snaga.org>

永安です。

別にどっちが正しいかの議論をしたいわけじゃなくて、
どう考えてるのか意見を聞きたかっただけなのですが。

池田　秀一 <hikeda ＠ miraclelinux.com> wrote:
> >  - なぜ DUAL という名前なのか？
> >  - そもそも、なぜ必要なのか

> 　すいません、俺も命名基準は知りません。また、まったく興味も
> ありません。たぶん、From 句で対応したかったのかなと類推する
> のはできますが。。
> 　で、その命名基準が判れば、納得できるとも思えませんが。。

命名基準が分かれば納得できるとは私も思ってませんが、
でも特に後者は知りたいとは思います。


> > # 「脈絡のないオブジェクト」という指摘は、それはそれで正しいと感じています（私は）。
> > 
> >  - 意味が先にあって、意味に文法を合わせるのか（FROM DUALが不要）
> >  - 文法が先にあって、文法に意味を合わせるのか（常にFROM句が必要）
> > 
> > の違いじゃないでしょうか。
> 
> その通りです。で、脈絡のない気持ち悪い点が、オブジェクトの
> 存在なのか？、From 句が無いのか？、の差でしかありません。

「脈絡がない」というのは論理的必然性が無いということであって、
「気持ち悪い」という主観的な話ではないと思うのですが。。


> > 「SQLの仕様に忠実だから正しい」というのは、そのレイヤーを見ればその通り
> > かもしれませんが、「そもそもSQLがなぜそういう仕様になっているのか」とい
> > うSQLの仕様自体が意味的に正しいかどうかとは別でしょう。
> 
> 逆に問います。では何を持って「正しいか」を議論したいのですか？
> 
> SQL仕様を基盤に話さないのであれば、感覚論に終始して意味が無い
> と考えます。他に基盤にできるモノがありますか？

前述したように、文法の前に意味（論理）があるのだとすれば、
その論理を基盤として議論することはできると思いますが。

仕様というのはそうやって決められるのではないのでしょうか？

かといって、その議論が生産的であるかどうかは知りません。

だから、

> # 「仕様に沿っていれば正しい」というのは、正しさの「一面」であって、
> # 意味的な正しさとは一致しない、しかし意味的な正しさが常に要求される
> # わけでもない、というのが私のスタンスです。

と書いたわけです。

> 「SQL仕様がおかしい」と主張するのは自由ですが、様々な標準化
> の中でも上手く行っているほうだと捉えます。ですので、SQL仕様
> と異なる独自拡張仕様を各社が独自に広げるのは良い事とは逆に
> 考えません。独自拡張は必要悪であり、積極的に行うべきことで
> はありません。

「標準」という言葉の意味を考えれば言うまでもないことですね。

> 繰り返しますが、「仕様バク」だと考えるのであれば、提供元に
> 伝えるのが「技術者としては誠実な行動」ではありませんか？
> って書いてる訳です。

私は別にバグだと言っているわけではなく、「そういういう考え方もあるなぁ」
と思っているだけです。

-- 
NAGAYASU Satoshi <snaga ＠ snaga.org>



From snaga ＠ snaga.org  Fri May 16 16:51:52 2003
From: snaga ＠ snaga.org (Satoshi Nagayasu)
Date: Fri, 16 May 2003 16:51:52 +0900
Subject: [pgsql-jp: 29928] Re: ORACLEでいう DUAL   表は？
In-Reply-To: <20030516163341.58c9534e.snaga@snaga.org>
References: <20030516144642.CDCE.HIKEDA@miraclelinux.com>
	<20030516152019.42c3b7b0.snaga@snaga.org>
	<20030516152939.CDD6.HIKEDA@miraclelinux.com>
	<20030516163341.58c9534e.snaga@snaga.org>
Message-ID: <20030516165152.1ba20fd0.snaga@snaga.org>

永安です。

すいません、補足です。

> > > 「SQLの仕様に忠実だから正しい」というのは、そのレイヤーを見ればその通り
> > > かもしれませんが、「そもそもSQLがなぜそういう仕様になっているのか」とい
> > > うSQLの仕様自体が意味的に正しいかどうかとは別でしょう。
> > 
> > 逆に問います。では何を持って「正しいか」を議論したいのですか？
> > 
> > SQL仕様を基盤に話さないのであれば、感覚論に終始して意味が無い
> > と考えます。他に基盤にできるモノがありますか？
> 
> 前述したように、文法の前に意味（論理）があるのだとすれば、
> その論理を基盤として議論することはできると思いますが。
> 
> 仕様というのはそうやって決められるのではないのでしょうか？

「決められるべきなのではないでしょうか？」の間違いです。

現状、仕様策定において、現状（独自拡張）追認の部分が
少なくないことは理解しています。

-- 
NAGAYASU Satoshi <snaga ＠ snaga.org>


From t-odaka ＠ novasystems.co.jp  Fri May 16 17:00:04 2003
From: t-odaka ＠ novasystems.co.jp (Tamotsu ODAKA)
Date: Fri, 16 May 2003 17:00:04 +0900
Subject: [pgsql-jp: 29929] Re: ORACLEでいう DUAL  表は？
References: <20030516144642.CDCE.HIKEDA@miraclelinux.com> <20030516152019.42c3b7b0.snaga@snaga.org> <20030516152939.CDD6.HIKEDA@miraclelinux.com>
Message-ID: <00aa01c31b81$28d22e20$2001010a@novasystems.co.jp>

尾高です。横からすみません。

「ただ深く考えず、仕事が出来ればいいや」という立場から。

> 池田です。
>
> >  - なぜ DUAL という名前なのか？
> >  - そもそも、なぜ必要なのか
> >
> > がよく分かりません。
>
> 　すいません、俺も命名基準は知りません。また、まったく興味も
> ありません。たぶん、From 句で対応したかったのかなと類推する
> のはできますが。。
> 　で、その命名基準が判れば、納得できるとも思えませんが。。
>
> > つまり、どういう必然性があってそうなっているのかが、理解しづらいんだと思
> > います。PostgreSQLでは存在していないわけですし、私自身も DUAL なるものが
> > 存在している必然性がよく理解できてません。
>
> 　繰り返すけど、どっちもどっちでしょう。

どうでもいいです。大勢に影響ありません。
でも、各ベンダ間でもう少し統一してもらえるといいですね。

> 　私は、汎用機上のデータベース(NEC ADBS,RIQS-II）、TeraData、
> BritonLee、Sybase、Oracle、SQL Server などに関わってきました
> が、その経験（慣れ）から『Select 文に From が無い方が非常に
> 気持ち悪い』です。で、実装理由を聞いても、感覚の問題だから
> 気持ちが悪いと言う個人の主観、感覚は変わらないですね。

私もいろいろ触ってますが、同感です。この感覚理解できます。

(以下省略)

ゴミですみません。

尾高 保 ( odaka ＠ novasystems.co.jp )



From naonuma ＠ ubiquitous.co.jp  Fri May 16 16:58:29 2003
From: naonuma ＠ ubiquitous.co.jp (Naomasa Numajiri)
Date: Fri, 16 May 2003 16:58:29 +0900
Subject: [pgsql-jp: 29930] Re: ORACLEでいう DUAL 表は？
In-Reply-To: <20030516152019.42c3b7b0.snaga@snaga.org>
References: <20030516144642.CDCE.HIKEDA@miraclelinux.com> <20030516152019.42c3b7b0.snaga@snaga.org>
Message-ID: <20030516163521.725F.NAONUMA@ubiquitous.co.jp>

こんにちは

# それぞれの歴史的経緯には興味があります。

On Fri, 16 May 2003 15:20:19 +0900
Satoshi Nagayasu <snaga ＠ snaga.org> wrote:

; 永安です。
; 
; Oracle知らないのに横からすみません。この話はときどき聞くので便乗です。
; 
---snip---
; 
;  - なぜ DUAL という名前なのか？
;  - そもそも、なぜ必要なのか

FROM句なしで実行できるようにする*必要がない*と判断したのだと思います。

シェルスクリプト上でpsql(or sqlplus)を起動して、色々やるなら
コーディングが少なくなって便利ですけど、そういう観点での要望が
顧客からなかったのだと思います。
対して、PostgreSQLはシェルスクリプトからの実行が便利になるような
要求が高かったように思えます。

; 
; がよく分かりません。
; 
---snip---
; 
; エンジニア的には、「別に使えりゃいいじゃん」ということなのかもしれません
; し、確かにそういう結論でも構わないとは思いますが。
; 

僕(Oracleに慣れています。参考までに。）のわがままとしては、
「SELECT SYSDATE」で実行するのではなく、「PRINT SYSDATE」や
「GET SYSDATE」などのようにSELECTを使わないか、「SYSDATE」
と単体で実行できるようになっていたら、(混乱がなくて)嬉しいです。


でわでわ

--ぬ


From kakura ＠ saki.netwk.ntt-at.co.jp  Fri May 16 17:10:13 2003
From: kakura ＠ saki.netwk.ntt-at.co.jp (Tetsuya Kakura)
Date: Fri, 16 May 2003 17:10:13 +0900
Subject: [pgsql-jp: 29931] Re: ORACLEでいう DUAL  表は？
In-Reply-To: <20030516152939.CDD6.HIKEDA@miraclelinux.com>
References: <20030516152939.CDD6.HIKEDA@miraclelinux.com>
Message-ID: <200305160810.AA06369@kakura.saki.netwk.ntt-at.co.jp>

加倉です。

池田　秀一 wrote on Fri, 16 May 2003 16:05:28 +0900

> 　すいません、俺も命名基準は知りません。また、まったく興味も
> ありません。たぶん、From 句で対応したかったのかなと類推する
> のはできますが。。
> 　で、その命名基準が判れば、納得できるとも思えませんが。。

こういうことのようです↓

http://otn.oracle.com/oramag/oracle/02-jan/o12sendmail.html

もともとは SYSDATE を取得する目的ではなかったようです。

--
Tetsuya Kakura / kakura ＠ saki.netwk.ntt-at.co.jp


From nakama ＠ ki.rim.or.jp  Fri May 16 17:14:24 2003
From: nakama ＠ ki.rim.or.jp (Ei-ji Nakama)
Date: Fri, 16 May 2003 17:14:24 +0900 (JST)
Subject: [pgsql-jp: 29932] Re: ORACLEでいう DUAL 表は？
In-Reply-To: <20030516163341.58c9534e.snaga@snaga.org>
References: <20030516152019.42c3b7b0.snaga@snaga.org>
	<20030516152939.CDD6.HIKEDA@miraclelinux.com>
	<20030516163341.58c9534e.snaga@snaga.org>
Message-ID: <20030516.171424.846962891.nakama@ki.rim.or.jp>

なかまです。

> > >  - なぜ DUAL という名前なのか？
> > >  - そもそも、なぜ必要なのか
> 
> > 　すいません、俺も命名基準は知りません。また、まったく興味も
> > ありません。たぶん、From 句で対応したかったのかなと類推する
> > のはできますが。。
> > 　で、その命名基準が判れば、納得できるとも思えませんが。。
> 
> 命名基準が分かれば納得できるとは私も思ってませんが、
> でも特に後者は知りたいとは思います。

http://otn.oracle.com/oramag/oracle/02-jan/o12sendmail.html

select sysdate from DUAL は有名ですが、由来は

select e.name,d.name,c.name
from   cat c,
       dept d,
       emp e,
       dual x
where  nvl('X', X.dummy) = nvl ('X', e.rowid(+))
and    nvl('X', X.dummy) = nvl ('X', d.rowid(+))
and    nvl('X', X.dummy) = nvl ('X', c.rowid(+))
and    e.emp_no (+) = 1234
and    d.dept_no (+) = 10
and    c.cat_type (+) = 'RD'

# Oracleのパフォーマンスチューニングより引用。

みたいな事(無関係のSQLを無理矢理一度でとってくる)を実現
するのが当初の目的のようです。

今は昔、selectのパースの遅さたるや脳の欠陥に悪影響を及ぼすこと
いと凄まじけり。
フェッチするや、のっそーり返って来ることこれ当然の事。
更に、2度もselectを発行する時たるや、眠気をもよおす事これ確実な
る。
プリコンパイル、コンパイルのmakeを流す間に、トイレとコーヒーが
所望可能。。。
# 昔話風によんでね。

で、無理矢理一度のselectで取りたくなるは、人情かと。
# そのへんのおっさんに聞けば、昔のRDBの評価が解かるかも。

実際、昔は良く使いましたが、最近では可読性が悪くなるので
使う事はわたしはありません。
# Oracle7が出て、しばらくしてパフォーマンスチューニングが
# 出たときDUALのjoinを見て歓喜の声をあげたのはわたしです。

--
e-mail : Ei-ji Nakama <nakama ＠ ki.rim.or.jp>


From no ＠ kasas.org  Fri May 16 17:21:57 2003
From: no ＠ kasas.org (KASAHARA Norio)
Date: Fri, 16 May 2003 17:21:57 +0900
Subject: [pgsql-jp: 29933] Re: ORACLEでいう DUAL  表は？
In-Reply-To: <20030516163521.725F.NAONUMA@ubiquitous.co.jp>
Message-ID: <75D33739-8777-11D7-A550-0003939D0DE6@kasas.org>

かさはらです。こんにちは。

On 2003.5.16, at 16:58 Japan, Naomasa Numajiri wrote:

> # それぞれの歴史的経緯には興味があります。
>
PostgreSQLがなぜFROMなしのSELECT文を認めているのかは、リファレンス
マニュアルのSELECT文の説明の「互換性」のところに記述があります。

シェルスクリプトからの実行うんぬんではなく、postgres時代との互換性からと
いうことです。
SQLが建て増しで汚くなっているのと同様に、PostgreSQLにもそれなりに事情
がある訳です。意味論的に美しいからという理由でないことは確かです。

--
カさはらのりお     no ＠ kasas.org



From snaga ＠ snaga.org  Fri May 16 17:20:16 2003
From: snaga ＠ snaga.org (Satoshi Nagayasu)
Date: Fri, 16 May 2003 17:20:16 +0900
Subject: [pgsql-jp: 29934] Re: ORACLEでいう DUAL  表は？
In-Reply-To: <20030516.171424.846962891.nakama@ki.rim.or.jp>
References: <20030516152019.42c3b7b0.snaga@snaga.org>
	<20030516152939.CDD6.HIKEDA@miraclelinux.com>
	<20030516163341.58c9534e.snaga@snaga.org>
	<20030516.171424.846962891.nakama@ki.rim.or.jp>
Message-ID: <20030516172016.0293a395.snaga@snaga.org>

永安です。

Ei-ji Nakama <nakama ＠ ki.rim.or.jp> wrote:
> > 命名基準が分かれば納得できるとは私も思ってませんが、
> > でも特に後者は知りたいとは思います。
> 
> http://otn.oracle.com/oramag/oracle/02-jan/o12sendmail.html
> 
> select sysdate from DUAL は有名ですが、由来は

> みたいな事(無関係のSQLを無理矢理一度でとってくる)を実現
> するのが当初の目的のようです。

おぉ、なるほど。何でも聞いてみるものですね。:-)

勉強になりました。m(__)m

-- 
NAGAYASU Satoshi <snaga ＠ snaga.org>


From naonuma ＠ ubiquitous.co.jp  Fri May 16 17:27:50 2003
From: naonuma ＠ ubiquitous.co.jp (Naomasa Numajiri)
Date: Fri, 16 May 2003 17:27:50 +0900
Subject: [pgsql-jp: 29935] Re: ORACLEでいう DUAL 表は？
In-Reply-To: <75D33739-8777-11D7-A550-0003939D0DE6@kasas.org>
References: <20030516163521.725F.NAONUMA@ubiquitous.co.jp> <75D33739-8777-11D7-A550-0003939D0DE6@kasas.org>
Message-ID: <20030516172119.7267.NAONUMA@ubiquitous.co.jp>

こんにちは、

僕の予想は間違っていました。(^^;

「PostgreSQLオフィシャルマニュアル」の
	PostgreSQL7.1 リファレンスガイド
	Part I SQLコマンド
の「SELECT/互換性(P.736-737)」の記述を確認しました。

PostQuelからの互換性のようですね。

# 「それほど明確ではない使用法」は、読んで「へー」と思いましたが
# 使うことはないと思います。

ありがとうございました。

--ぬ

On Fri, 16 May 2003 17:21:57 +0900
KASAHARA Norio <no ＠ kasas.org> wrote:

; かさはらです。こんにちは。
; 
; On 2003.5.16, at 16:58 Japan, Naomasa Numajiri wrote:
; 
; > # それぞれの歴史的経緯には興味があります。
; >
; PostgreSQLがなぜFROMなしのSELECT文を認めているのかは、リファレンス
; マニュアルのSELECT文の説明の「互換性」のところに記述があります。
; 
; シェルスクリプトからの実行うんぬんではなく、postgres時代との互換性からと
; いうことです。
; SQLが建て増しで汚くなっているのと同様に、PostgreSQLにもそれなりに事情
; がある訳です。意味論的に美しいからという理由でないことは確かです。
; 
; --
; カさはらのりお     no ＠ kasas.org
; 



From t-ishii ＠ sra.co.jp  Fri May 16 18:44:40 2003
From: t-ishii ＠ sra.co.jp (Tatsuo Ishii)
Date: Fri, 16 May 2003 18:44:40 +0900 (JST)
Subject: [pgsql-jp: 29936] Re: ORACLEでいう DUAL 表は？
In-Reply-To: <75D33739-8777-11D7-A550-0003939D0DE6@kasas.org>
References: <20030516163521.725F.NAONUMA@ubiquitous.co.jp>
	<75D33739-8777-11D7-A550-0003939D0DE6@kasas.org>
Message-ID: <20030516.184440.115904347.t-ishii@sra.co.jp>

石井です．

> PostgreSQLがなぜFROMなしのSELECT文を認めているのかは、リファレンス
> マニュアルのSELECT文の説明の「互換性」のところに記述があります。
> 
> シェルスクリプトからの実行うんぬんではなく、postgres時代との互換性からと
> いうことです。

はい，そうです．これは割と有名な話ですね．

> SQLが建て増しで汚くなっているのと同様に、PostgreSQLにもそれなりに事情
> がある訳です。意味論的に美しいからという理由でないことは確かです。

それは単にSQLよりはPostQuelあるいはQuelの方が美しかった，ということを
示しているだけではないでしょうか．

ここでちょっとバランスを取って:-)SQLを擁護しておくと...

いろいろけなされるSQLですが，それなりに頑張っているところもあるんでは
ないでしょうか．たとえば，JOIN構文の導入によって，ベンダーごとに様々
（かつできの悪い）構文だった外部結合が整理されたところは重要な貢献だっ
たと思います．

# SQLを言語だと思うととても付き合いきれませんが，パズルだと思えば結
# 構楽しめます:-)
--
Tatsuo Ishii


From hikeda ＠ miraclelinux.com  Fri May 16 18:49:53 2003
From: hikeda ＠ miraclelinux.com (池田　秀一)
Date: Fri, 16 May 2003 18:49:53 +0900
Subject: [pgsql-jp: 29937] Re: ORACLEでいう DUAL 表は？
In-Reply-To: <20030516.184440.115904347.t-ishii@sra.co.jp>
References: <75D33739-8777-11D7-A550-0003939D0DE6@kasas.org> <20030516.184440.115904347.t-ishii@sra.co.jp>
Message-ID: <20030516184729.DFD9.HIKEDA@miraclelinux.com>

池田です。

> それは単にSQLよりはPostQuelあるいはQuelの方が美しかった，ということを
> 示しているだけではないでしょうか．

　汎用機、ミニコン、オフコンなどの独自データベースにおける
コマンド言語もシンプルで美しいモノもありました。

> # SQLを言語だと思うととても付き合いきれませんが，パズルだと思えば結
> # 構楽しめます:-)

　同感です。

　システム構築って、制約事項の中でバランスを取る仕事だと
言う気もします。パズルを解く、もしくは、落とし所を決める
という感覚かも。

-- -- -- -- -- -- -- -- 
池田　秀一 <ikeda ＠ miraclelinux.com>    Hidekazu Ikeda  
 Sales Division, Business Development,  Director 
　TEL: 03-5562-8310  Fax: 03-5562-8306 
----------  
Oracle9i Database Linux版キャンペーン　 2003/9/30迄
--★MIRACLE LINUX お知らせ★-----------------------
申┃込┃受┃付┃中┃MIRACLE LINUX プロダクトサポート
━┛━┛━┛━┛━┛〜品質向上計画　発動中！！〜　　
http://www.miraclelinux.co.jp/support/product.html
----------------------------------------------------------------------



From ogino ＠ sic.co.jp  Fri May 16 19:29:14 2003
From: ogino ＠ sic.co.jp (Ogino)
Date: Fri, 16 May 2003 19:29:14 +0900
Subject: [pgsql-jp: 29938] 特定の日本語を含むとエラー
Message-ID: <200305161026.TAA00757@asagao.sic.co.jp>

お世話になっています。荻野といいます。

今、PostgreSQL7.3.2＋RedHat8.0+JDK1.4.1
でシステムを作っています。

以下のようなテーブルに、JDBC経由でアクセスすると
エラーを吐いて落ちてしまいます。

[テーブル：キーワード]
create table keyword(
	key_id integer,
	keyword varchar(100),
	kana varchar(100)
);

insert into keyword values(
	1,'睡眠時無呼吸症','すいみんじむこきゅうしょう');

select * from keyword 
	where keyword = '睡眠時無呼吸症' ;

エラーの内容は、以下の通りです。
The backend has broken the connection. Possibly the action you have attempted has caused it to close.
        at org.postgresql.PG_Stream.ReceiveChar(PG_Stream.java:140)
        at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:76)
        at org.postgresql.jdbc1.AbstractJdbc1Connection.ExecSQL(AbstractJdbc1Connection.java:505)
        at org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Statement.java:320)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:48)
        at org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:153)
        at org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:141)
        at org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:162)

これを見る限り、PG_Streamクラスで落ちているので、
このクラスを見たところ、以下のような記述がありました。

public int ReceiveChar() throws SQLException
{
	int c = 0;
	
	try
	{
	        c = pg_input.read();
	        if (c < 0)
	                throw new PSQLException("postgresql.stream.eof");
	}
	catch (IOException e)
	{
	        throw new PSQLException("postgresql.stream.ioerror", e);
	}
	return c;
}

簡単に言うと、Streamから何もデータを得られていない
様子です。しかし、同じテーブルに

insert into keyword values(2,'胃','い');

と入力して、select * from keyword where keyword = '胃';
とすると、正常に返ってきます。
その後の調査の結果、呼吸の「呼」の字があると
エラーになってしまうようです。
Postgresのサーバログには、

LOG:  database system was shut down at 2003-05-15 19:40:49 JST
LOG:  checkpoint record is at 0/4514580
LOG:  redo record is at 0/4514580; undo record is at 0/0; shutdown TRUE
LOG:  next transaction id: 49702; next oid: 57268
LOG:  database system is ready

のような記述が有ります。

これはUnicodeの問題なのでしょうか？
でも、psqlから実行するとうまくいきます。
とすると、JDBCドライバの問題なのかなとも
思います。

ご存知の方がいましたら、知恵を拝借したいと
思っております。よろしくお願いします。

ちなみに、JDBCはソースからコンパイルしています。









From formsoft ＠ tcct.zaq.ne.jp  Fri May 16 06:03:16 2003
From: formsoft ＠ tcct.zaq.ne.jp (Ryo Kunieda)
Date: Fri, 16 May 2003 06:03:16 +0900
Subject: [pgsql-jp: 29939] Re: INSERT で作成したカラムのSERIAL 値の取り出し方
In-Reply-To: <20030514212811.GA1194%hi-takada@k5.dion.ne.jp>
References: <v04210a01bae8563c5492@[192.168.128.10]>
 <20030514212811.GA1194%hi-takada@k5.dion.ne.jp>
Message-ID: <v04210a00bae9aede08fb@[192.168.128.10]>

> SELECT currval('シーケンス名');
>
> で取得できます。この例だと、
>
> SELECT currval('member_id_seq');
>
> となります。

ありがとう御座いました。参考にしている本をcurrvalで引き直してみると、シーケ
ンスの項目に記述がありました。
一度は見ているはずなんですが、良く理解できなかったためか記憶に全くありません
でした


> currval は現在のセッションにおいて、 最後に実行された nextval の値が
> 保存されているので、他のセッションで member テーブルにレコードが追加
> されたかどうかをケアする必要がありません。

これが気になっていたのですが、問題なさそうです。

ありがとう御座いました。

----------------------------------------------------------------
formsoft ＠ tcct.zaq.ne.jp (FormSoftware)
Ryo Kunieda -  FormSoftware
Osaka, Japan　Tel:+81-6-6335-6266 Fax:+81-6-6335-6276
----------------------------------------------------------------


From ogino ＠ sic.co.jp  Sat May 17 13:06:23 2003
From: ogino ＠ sic.co.jp (Ogino)
Date: Sat, 17 May 2003 13:06:23 +0900
Subject: [pgsql-jp: 29940] Re: 特定の日本語を含むとエラー
In-Reply-To: <200305161026.TAA00757@asagao.sic.co.jp>
References: <200305161026.TAA00757@asagao.sic.co.jp>
Message-ID: <200305170404.NAA10369@asagao.sic.co.jp>

荻野です。自己レスです。

> 以下のようなテーブルに、JDBC経由でアクセスすると
> エラーを吐いて落ちてしまいます。
> 
> [テーブル：キーワード]
> create table keyword(
> 	key_id integer,
> 	keyword varchar(100),
> 	kana varchar(100)
> );
> 
> insert into keyword values(
> 	1,'睡眠時無呼吸症','すいみんじむこきゅうしょう');
> 
> select * from keyword 
> 	where keyword = '睡眠時無呼吸症' ;
> 

理由は良く分かりませんが、「睡眠時無呼吸症」
という日本語をEUCに変換したところ、
うまくいくようになりました。
しかし、DBはNUICODEで作ってあるので、
なぜこれでうまくいくのかかなり疑問です。
(PGCLIENTENCODINGもUNICODEです）

その後、新たな問題が起こりました。
同様に、'睡眠時無呼吸症'　という単語を
キーにして、以下のような正規表現で検索をしていた
のですが、やはり「呼」の字があると
同様のエラーを吐いて落ちてしまいました。
(PSQLからでも落ちます）

select * from hoge where name ~ '睡眠時無呼吸症'

こちらについては、LIKEにすることで
回避することができるのでいいのですが、
日本語を使った正規表現は、まだまだなのかな？
と思いました。

以上です。
お騒がせしてすみませんでした。






From brandy ＠ hyper.cx  Sat May 17 13:28:27 2003
From: brandy ＠ hyper.cx (Brandy)
Date: Sat, 17 May 2003 13:28:27 +0900
Subject: [pgsql-jp: 29941] SQLの最大の長さ
Message-ID: <20030517042827.81932.qmail@mail5.zenno.net>

Brandyです。

PostgresSQL 7.2.3を使用してます。

あるSQL(insert)を発行すると
SQLが長すぎると怒られて
insertが実行できません。

SQLの長さの最大値は
どのようにして設定変更できるので
しょうか？

宜しくお願いします。




From sugita ＠ sra.co.jp  Sat May 17 13:58:19 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Sat, 17 May 2003 13:58:19 +0900 (JST)
Subject: [pgsql-jp: 29942] Re: SQLの最大の長さ
In-Reply-To: <20030517042827.81932.qmail@mail5.zenno.net>
References: <20030517042827.81932.qmail@mail5.zenno.net>
Message-ID: <20030517.135819.41652156.sugita@sra.co.jp>

  杉田です。

From: Brandy <brandy ＠ hyper.cx>
Subject: [pgsql-jp: 29941] SQLの最大の長さ
Date: Sat, 17 May 2003 13:28:27 +0900

;;; PostgresSQL 7.2.3を使用してます。
;;; 
;;; あるSQL(insert)を発行すると
;;; SQLが長すぎると怒られて
;;; insertが実行できません。

  その SQL の実際の長さと具体的なメッセージはどのようでしょうか?


Kenji Sugita                                      


From brandy ＠ hyper.cx  Sat May 17 14:10:00 2003
From: brandy ＠ hyper.cx (Brandy)
Date: Sat, 17 May 2003 14:10:00 +0900
Subject: [pgsql-jp: 29943] Re: SQLの最大の長さ
In-Reply-To: <20030517.135819.41652156.sugita@sra.co.jp>
References: <20030517.135819.41652156.sugita@sra.co.jp>
Message-ID: <20030517051000.29019.qmail@mail5.zenno.net>

Brandyです。

杉田さまありがとうございます。

>   その SQL の実際の長さと具体的なメッセージはどのようでしょうか?

メッセージ：query is too long
長さ：8192

今まで調べた結果
PostgreSQLは1行のサイズが8192バイトに制限されている
とわかったのですが、
7.2.3でもその制限があるということでしょうか？

最大値を解除もしくは増加できるのであれば
方法をご教授ください。



>   杉田です。
> 
> From: Brandy <brandy ＠ hyper.cx>
> Subject: [pgsql-jp: 29941] SQLの最大の長さ
> Date: Sat, 17 May 2003 13:28:27 +0900
> 
> ;;; PostgresSQL 7.2.3を使用してます。
> ;;; 
> ;;; あるSQL(insert)を発行すると
> ;;; SQLが長すぎると怒られて
> ;;; insertが実行できません。
> 
>   その SQL の実際の長さと具体的なメッセージはどのようでしょうか?
> 
> 
> Kenji Sugita                                      



From sugita ＠ sra.co.jp  Sat May 17 14:31:03 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Sat, 17 May 2003 14:31:03 +0900 (JST)
Subject: [pgsql-jp: 29944] Re: SQLの最大の長さ
In-Reply-To: <20030517051000.29019.qmail@mail5.zenno.net>
References: <20030517.135819.41652156.sugita@sra.co.jp>
	<20030517051000.29019.qmail@mail5.zenno.net>
Message-ID: <20030517.143103.71105905.sugita@sra.co.jp>

  杉田です。

From: Brandy <brandy ＠ hyper.cx>
Subject: [pgsql-jp: 29943] Re: SQLの最大の長さ
Date: Sat, 17 May 2003 14:10:00 +0900

;;; >   その SQL の実際の長さと具体的なメッセージはどのようでしょうか?
;;; 
;;; メッセージ：query is too long
;;; 長さ：8192

  PostgreSQL 7.2.3 のソースで、"query is too long" に一番近そうなメッセージは、
以下の最後のメッセージのようです。このメッセージでしょうか?

    $ find . -type f -exec grep -i query {} /dev/null \; | grep -i too | grep -i long
    ./doc/TODO.detail/async:because that will cause application failures as well (too long query
    ./src/bin/psql/tab-complete.c:#define ERROR_QUERY_TOO_LONG      /* empty */
    ./src/bin/psql/tab-complete.c:                  ERROR_QUERY_TOO_LONG;
    ./src/bin/psql/tab-complete.c:                  ERROR_QUERY_TOO_LONG;
    ./src/bin/psql/tab-complete.c:          ERROR_QUERY_TOO_LONG;
    ./src/interfaces/odbc/connection.c:             self->errormsg = "Query string is too long";
    $ 


Kenji Sugita                                      



From brandy ＠ hyper.cx  Sat May 17 14:36:35 2003
From: brandy ＠ hyper.cx (Brandy)
Date: Sat, 17 May 2003 14:36:35 +0900
Subject: [pgsql-jp: 29945] Re: SQLの最大の長さ
In-Reply-To: <20030517.143103.71105905.sugita@sra.co.jp>
References: <20030517.143103.71105905.sugita@sra.co.jp>
Message-ID: <20030517053635.57196.qmail@mail5.zenno.net>

Brandyです。

杉田さまありがとうございます。

> 以下の最後のメッセージのようです。このメッセージでしょうか?

はい。このメッセージです。
すません、私が表記したものはとちょっと違いましたね。。

下記メッセージはどのようなときに出力されるのでしょうか？

>   杉田です。
> 
> From: Brandy <brandy ＠ hyper.cx>
> Subject: [pgsql-jp: 29943] Re: SQLの最大の長さ
> Date: Sat, 17 May 2003 14:10:00 +0900
> 
> ;;; >   その SQL の実際の長さと具体的なメッセージはどのようでしょうか?
> ;;; 
> ;;; メッセージ：query is too long
> ;;; 長さ：8192
> 
>   PostgreSQL 7.2.3 のソースで、"query is too long" に一番近そうなメッセージは、
> 以下の最後のメッセージのようです。このメッセージでしょうか?
> 
>     $ find . -type f -exec grep -i query {} /dev/null \; | grep -i too | grep -i long
>     ./doc/TODO.detail/async:because that will cause application failures as well (too long query
>     ./src/bin/psql/tab-complete.c:#define ERROR_QUERY_TOO_LONG      /* empty */
>     ./src/bin/psql/tab-complete.c:                  ERROR_QUERY_TOO_LONG;
>     ./src/bin/psql/tab-complete.c:                  ERROR_QUERY_TOO_LONG;
>     ./src/bin/psql/tab-complete.c:          ERROR_QUERY_TOO_LONG;
>     ./src/interfaces/odbc/connection.c:             self->errormsg = "Query string is too long";
>     $ 
> 
> 
> Kenji Sugita                                      
> 



From e-tokuya ＠ sankyo-unyu.jp  Sat May 17 14:40:39 2003
From: e-tokuya ＠ sankyo-unyu.jp (Eiji Tokuya)
Date: Sat, 17 May 2003 14:40:39 +0900
Subject: [pgsql-jp: 29946] Re: 特定の日本語を含むとエラー
In-Reply-To: <200305170404.NAA10369@asagao.sic.co.jp>
References: <200305161026.TAA00757@asagao.sic.co.jp> <200305170404.NAA10369@asagao.sic.co.jp>
Message-ID: <3EC5CB57.4000108@sankyo-unyu.jp>

徳家です。

JDBCの設定の事が書いていないのですが・・・。
私はJDBCを使っていませんが、ひょとして、JDBCの設定がEUC-JP
などになっていたのではないでしょうか？

UNICODEのDBに対して、EUC_JPのデータは強引に入力はできますが、
文字列の長さを正しく識別できないのでトラブルの原因になります。
エンコーディングは正しく設定して利用して下さいね。


Ogino wrote:
> 荻野です。自己レスです。
> 
> 
>>以下のようなテーブルに、JDBC経由でアクセスすると
>>エラーを吐いて落ちてしまいます。
>>
>>[テーブル：キーワード]
>>create table keyword(
>>	key_id integer,
>>	keyword varchar(100),
>>	kana varchar(100)
>>);
>>
>>insert into keyword values(
>>	1,'睡眠時無呼吸症','すいみんじむこきゅうしょう');
>>
>>select * from keyword 
>>	where keyword = '睡眠時無呼吸症' ;
>>
> 
> 
> 理由は良く分かりませんが、「睡眠時無呼吸症」
> という日本語をEUCに変換したところ、
> うまくいくようになりました。
> しかし、DBはNUICODEで作ってあるので、
> なぜこれでうまくいくのかかなり疑問です。
> (PGCLIENTENCODINGもUNICODEです）
> 
> その後、新たな問題が起こりました。
> 同様に、'睡眠時無呼吸症'　という単語を
> キーにして、以下のような正規表現で検索をしていた
> のですが、やはり「呼」の字があると
> 同様のエラーを吐いて落ちてしまいました。
> (PSQLからでも落ちます）
> 
> select * from hoge where name ~ '睡眠時無呼吸症'
> 
> こちらについては、LIKEにすることで
> 回避することができるのでいいのですが、
> 日本語を使った正規表現は、まだまだなのかな？
> と思いました。
> 
> 以上です。
> お騒がせしてすみませんでした。



From toshitaka.iso ＠ hp.com  Sat May 17 19:20:58 2003
From: toshitaka.iso ＠ hp.com (Iso, Toshitaka)
Date: Sat, 17 May 2003 19:20:58 +0900
Subject: [pgsql-jp: 29947] SET STATISTICS の統計情報の目標値決定指標
Message-ID: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E0234065D@tkoexc02.asiapacific.cpqcorp.net>

いつもお世話になっております。

2000万レコードのデータ件数のあるテーブルでSeqscanが
走ってしまい困っております。

ALTER TABLE テーブル名 ALTER COLUMN SET STATISTICS N;

でテーブル単位に統計目標値を変えようと思っているのですが、
何か指標等があるのでしょうか？（レコード件数やデータサイズによってなど・・・）

今のところは全テーブルがデフォルトの10で稼動しており、これを変えてAnalyze
をかけたいと考えております。

また、変えたことによるリスク等があればお教えいただけたら幸いです。

以上です。よろしくお願いいたします。


From sugita ＠ sra.co.jp  Sat May 17 20:47:38 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Sat, 17 May 2003 20:47:38 +0900 (JST)
Subject: [pgsql-jp: 29948] Re: SET STATISTICS の統計情報の目標値決定指標
In-Reply-To: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E0234065D@tkoexc02.asiapacific.cpqcorp.net>
References: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E0234065D@tkoexc02.asiapacific.cpqcorp.net>
Message-ID: <20030517.204738.78729265.sugita@sra.co.jp>

  杉田です。

From: "Iso, Toshitaka" <toshitaka.iso ＠ hp.com>
Subject: [pgsql-jp: 29947] SET STATISTICS の統計情報の目標値決定指標
Date: Sat, 17 May 2003 19:20:58 +0900

;;; 2000万レコードのデータ件数のあるテーブルでSeqscanが
;;; 走ってしまい困っております。

  今迄は、そうでなかったというのでしょうから、何らかの変更ないし変化があったの
ではないでしょうか? データだけでなく、アプリケーション側のクエリーの変更も含め
てです。

;;; ALTER TABLE テーブル名 ALTER COLUMN SET STATISTICS N;

  これは、ひとつの手段ですが、どのように問題が発生したかが把握できないと、必ず
しも有効かどうかは決められません。

;;; でテーブル単位に統計目標値を変えようと思っているのですが、
;;; 何か指標等があるのでしょうか？（レコード件数やデータサイズによってなど・・・）

  日付項目を文字列で保持した上にインデックスにするような設計上のバグの場合はそ
れなりの修正負担が必要です。データの分布のピークが分かれば bin の数をどれくら
いにすればよいか予想はできます。

;;; 今のところは全テーブルがデフォルトの10で稼動しており、これを変えてAnalyze
;;; をかけたいと考えております。

  全部の bin を細分化する必要はないはずで、特定のテーブルが対象となると思えま
す。

;;; また、変えたことによるリスク等があればお教えいただけたら幸いです。

  bin の数が増える分の負荷は増えます。


Kenji Sugita                                      




From toshitaka.iso ＠ hp.com  Sat May 17 23:36:14 2003
From: toshitaka.iso ＠ hp.com (Iso, Toshitaka)
Date: Sat, 17 May 2003 23:36:14 +0900
Subject: [pgsql-jp: 29949] Re: SET STATISTICS の統計情報の目標値決定指標
Message-ID: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E021CC8BF@tkoexc02.asiapacific.cpqcorp.net>

杉田さん。

いつも大変お世話になっております。それとご返答ありがとうございます。

> 今迄は、そうでなかったというのでしょうから、何らかの変更ないし変化があったの
> ではないでしょうか? データだけでなく、アプリケーション側のクエリーの変更も含め
> てです。

変わったとしたらデータ量です。今まで発行していたSQLは
select * from tbl_hoge where kubun='010101';
のようなSQLを発行しており、kubunカラムには単一でIndexが付与されていますが
Seq Scanが走ってしまう場合があります。

パターンを調べてみたところ・・・

【Seq Scanが走るパターン】
kubunで絞り込んでも、20万件以上ある場合

【Index Scanが走るパターン】
kubunで絞り込むと、2万件以下に絞り込める場合

まだまだ細かいパターンがあるのかと思いますが、上記のような結果となりました。

検索しようとしているkubun値の割合が〜%以上の場合はSeq Scanになると
かいう指標とかあるのでしょうか？

お忙しいところ申し訳ありません。
よろしければご教授ください。

以上です。

-----Original Message-----
From: sugita ＠ sra.co.jp [mailto:sugita ＠ sra.co.jp] 
Sent: Saturday, May 17, 2003 8:48 PM
To: pgsql-jp ＠ ml.postgresql.jp
Subject: [pgsql-jp: 29948] Re: SET STATISTICS の統計情報の目標値決定指標


  杉田です。

From: "Iso, Toshitaka" <toshitaka.iso ＠ hp.com>
Subject: [pgsql-jp: 29947] SET STATISTICS の統計情報の目標値決定指標
Date: Sat, 17 May 2003 19:20:58 +0900

;;; 2000万レコードのデータ件数のあるテーブルでSeqscanが
;;; 走ってしまい困っております。

  今迄は、そうでなかったというのでしょうから、何らかの変更ないし変化があったの
ではないでしょうか? データだけでなく、アプリケーション側のクエリーの変更も含め
てです。

;;; ALTER TABLE テーブル名 ALTER COLUMN SET STATISTICS N;

  これは、ひとつの手段ですが、どのように問題が発生したかが把握できないと、必ず
しも有効かどうかは決められません。

;;; でテーブル単位に統計目標値を変えようと思っているのですが、
;;; 何か指標等があるのでしょうか？（レコード件数やデータサイズによってなど・・・）

  日付項目を文字列で保持した上にインデックスにするような設計上のバグの場合はそ
れなりの修正負担が必要です。データの分布のピークが分かれば bin の数をどれくら
いにすればよいか予想はできます。

;;; 今のところは全テーブルがデフォルトの10で稼動しており、これを変えてAnalyze
;;; をかけたいと考えております。

  全部の bin を細分化する必要はないはずで、特定のテーブルが対象となると思えま
す。

;;; また、変えたことによるリスク等があればお教えいただけたら幸いです。

  bin の数が増える分の負荷は増えます。


Kenji Sugita                                      




From t-ishii ＠ sra.co.jp  Sun May 18 10:25:17 2003
From: t-ishii ＠ sra.co.jp (Tatsuo Ishii)
Date: Sun, 18 May 2003 10:25:17 +0900 (JST)
Subject: [pgsql-jp: 29950] Re: 特定の日本語を含むとエラー
In-Reply-To: <200305170404.NAA10369@asagao.sic.co.jp>
References: <200305161026.TAA00757@asagao.sic.co.jp>
	<200305170404.NAA10369@asagao.sic.co.jp>
Message-ID: <20030518.102517.74755121.t-ishii@sra.co.jp>

石井です．

> > 以下のようなテーブルに、JDBC経由でアクセスすると
> > エラーを吐いて落ちてしまいます。
> > 
> > [テーブル：キーワード]
> > create table keyword(
> > 	key_id integer,
> > 	keyword varchar(100),
> > 	kana varchar(100)
> > );
> > 
> > insert into keyword values(
> > 	1,'睡眠時無呼吸症','すいみんじむこきゅうしょう');
> > 
> > select * from keyword 
> > 	where keyword = '睡眠時無呼吸症' ;
> > 
> 
> 理由は良く分かりませんが、「睡眠時無呼吸症」
> という日本語をEUCに変換したところ、
> うまくいくようになりました。
> しかし、DBはNUICODEで作ってあるので、
> なぜこれでうまくいくのかかなり疑問です。
> (PGCLIENTENCODINGもUNICODEです）
> 
> その後、新たな問題が起こりました。
> 同様に、'睡眠時無呼吸症'　という単語を
> キーにして、以下のような正規表現で検索をしていた
> のですが、やはり「呼」の字があると
> 同様のエラーを吐いて落ちてしまいました。
> (PSQLからでも落ちます）
> 
> select * from hoge where name ~ '睡眠時無呼吸症'

そりゃそうでしょう．テーブル名も列名も間違っていますから．

> こちらについては、LIKEにすることで
> 回避することができるのでいいのですが、
> 日本語を使った正規表現は、まだまだなのかな？
> と思いました。

ここ数年日本語正規表現に関する障害は見たことがありません．たまにバグレ
ポートが出てきますが，すべて使い方が悪かったのが原因です．

おそらくinitdbするときに --no-locale オプションを付けていないのじゃな
いですか?RedHat系は日本語のロケールデータベースが腐っているので，ロケー
ルサポートを有効にして日本語を使うとまずまともに動きません．

ちなみに，ここで提示されている例題はすべて私の環境ではまともに動きます．
(Vine Linux 2.1CR + PostgreSQL 7.3.2 + Unicode datatabase)
--
Tatsuo Ishii


From sugita ＠ sra.co.jp  Sun May 18 10:16:48 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Sun, 18 May 2003 10:16:48 +0900 (JST)
Subject: [pgsql-jp: 29951] Re: SET STATISTICS の統計情報の目標値決定指標
In-Reply-To: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E021CC8BF@tkoexc02.asiapacific.cpqcorp.net>
References: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E021CC8BF@tkoexc02.asiapacific.cpqcorp.net>
Message-ID: <20030518.101648.71111860.sugita@sra.co.jp>

  杉田です。

From: "Iso, Toshitaka" <toshitaka.iso ＠ hp.com>
Subject: [pgsql-jp: 29949] Re: SET STATISTICS の統計情報の目標値決定指標
Date: Sat, 17 May 2003 23:36:14 +0900

;;; いつも大変お世話になっております。それとご返答ありがとうございます。

  こちらこそです。

;;; > 今迄は、そうでなかったというのでしょうから、何らかの変更ないし変化があったの
;;; > ではないでしょうか? データだけでなく、アプリケーション側のクエリーの変更も含め
;;; > てです。
;;; 
;;; 変わったとしたらデータ量です。

  データ量のみが同じ分布傾向で増えたと仮定するならば、単純に考えて、2 倍になっ
たのならば、2 倍の数の bin にするというのはどうでしょう?

;;; 				  今まで発行していたSQLは
;;; select * from tbl_hoge where kubun='010101';
;;; のようなSQLを発行しており、kubunカラムには単一でIndexが付与されていますが
;;; Seq Scanが走ってしまう場合があります。
;;; 
;;; パターンを調べてみたところ・・・
;;; 
;;; 【Seq Scanが走るパターン】
;;; kubunで絞り込んでも、20万件以上ある場合
;;; 
;;; 【Index Scanが走るパターン】
;;; kubunで絞り込むと、2万件以下に絞り込める場合
;;; 
;;; まだまだ細かいパターンがあるのかと思いますが、上記のような結果となりました。

  他の要因がないとは言えないので、まずは、EXPLAIN ANALYZE の結果をみないと何と
も言えません。

;;; 検索しようとしているkubun値の割合が〜%以上の場合はSeq Scanになると
;;; かいう指標とかあるのでしょうか？

  単にぎっしり詰まっているとは限りませんので、75〜90% の範囲ではないでしょうか。
簡単な表で、実際にデータ入れて、データの更新や削除をすると確かめられます。削除
されているデータの分布の具合によっては、10% 程シーケンシャルスキャンの方が速く
ても、遅い方のインデックスキャンが実行される場合もあったりもします。10% 程度な
らば誤差の内です。


Kenji Sugita                                      


From sugita ＠ sra.co.jp  Sun May 18 11:09:56 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Sun, 18 May 2003 11:09:56 +0900 (JST)
Subject: [pgsql-jp: 29952] Re: SET STATISTICS の統計情報の目標値決定指標
In-Reply-To: <20030518.101648.71111860.sugita@sra.co.jp>
References: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E021CC8BF@tkoexc02.asiapacific.cpqcorp.net>
	<20030518.101648.71111860.sugita@sra.co.jp>
Message-ID: <20030518.110956.104060512.sugita@sra.co.jp>

  杉田です。

From: sugita ＠ sra.co.jp
Subject: [pgsql-jp: 29951] Re: SET STATISTICS の統計情報の目標値決定指標
Date: Sun, 18 May 2003 10:16:48 +0900 (JST)

;;;   単にぎっしり詰まっているとは限りませんので、75〜90% の範囲ではないでしょうか。

  これは、分布が単調な場合で、分布が単調でない場合は、もっと下がります。  


Kenji Sugita                                      



From matsui ＠ tono-k.jp  Sun May 18 11:22:44 2003
From: matsui ＠ tono-k.jp (k_matsui)
Date: Sun, 18 May 2003 11:22:44 +0900
Subject: [pgsql-jp: 29953] 40万件有るデータから重複をさけて登録する
Message-ID: <000d01c31ce4$6157a180$0b01a8c0@tono>

初めて質問させて頂きます。マツイと申します。
postgres初心者ですがよろしくお願いします。

現在web上からの応募フォームを作成中です。応募フォームをphpで作成し、
postgresに貯めていくというものです。
だいた40万件の応募が予想されるのですが、重複したメールアドレスでの
再応募が出来ないようにしたいのです。この場合、どのような方法が
簡単かつ、実用的でしょうか？尚、応募は3回に分けて行われ、1つの応募に
対して1度、計3回のメールアドレスでの応募が可能なようにしたいのですが、
tableは１つにまとめたいのです。

phpでデータを一度呼び出してメールアドレスをチェックしていたら件数的に実用的
では
ないような気がします。

それとも応募期間が終了してから重複したメールアドレスを排除するほうが良い
でしょうか？

OS：turbolinux
postgres7.1.3

良い解決策の解る方、なにとぞご教授お願い致すます。




From snaga ＠ snaga.org  Sun May 18 11:54:49 2003
From: snaga ＠ snaga.org (Satoshi Nagayasu)
Date: Sun, 18 May 2003 11:54:49 +0900
Subject: [pgsql-jp: 29954] Re: 40万件有るデータから重複をさけて登録する
In-Reply-To: <000d01c31ce4$6157a180$0b01a8c0@tono>
References: <000d01c31ce4$6157a180$0b01a8c0@tono>
Message-ID: <20030518115449.4542068d.snaga@snaga.org>

永安です。

# SQLは苦手なのですが、、

"k_matsui" <matsui ＠ tono-k.jp> wrote:
> 初めて質問させて頂きます。マツイと申します。
> postgres初心者ですがよろしくお願いします。
> 
> 現在web上からの応募フォームを作成中です。応募フォームをphpで作成し、
> postgresに貯めていくというものです。
> だいた40万件の応募が予想されるのですが、重複したメールアドレスでの
> 再応募が出来ないようにしたいのです。この場合、どのような方法が
> 簡単かつ、実用的でしょうか？尚、応募は3回に分けて行われ、1つの応募に
> 対して1度、計3回のメールアドレスでの応募が可能なようにしたいのですが、
> tableは１つにまとめたいのです。
> 
> phpでデータを一度呼び出してメールアドレスをチェックしていたら件数的に実用的
> では
> ないような気がします。
> 
> それとも応募期間が終了してから重複したメールアドレスを排除するほうが良い
> でしょうか？
> 
> OS：turbolinux
> postgres7.1.3
> 
> 良い解決策の解る方、なにとぞご教授お願い致すます。
> 
> 

いい解決策なのかどうか分からないのですが、

CREATE TABLE t1 (
  email text,
  count integer,

  CONSTRAINT email_count_key PRIMARY KEY ( email, count ),
  CONSTRAINT count_check CHECK(count>=0 and count<=2)
);

というようなテーブルを作って、

  1.) count を 0 にして INSERT
  2.) 1.)に失敗したら、count を 1 にして INSERT
  3.) 2.)に失敗したら、count を 2 にして INSERT
  4.) 3.)に失敗したら、4回目なのでエラー

というのはどうでしょうか？

とりあえず、遊んでみたんですが、以下のようになりました。

snaga=# \d t1 
          Table "t1"
 Column |  Type   | Modifiers 
--------+---------+-----------
 email  | text    | not null
 count  | integer | not null
Primary key: email_count_key
Check constraints: "count_check" ((count >= 0) AND (count <= 2))

snaga=# insert into t1 values ( 'snaga ＠ snaga.org', 0);
INSERT 7327403 1
snaga=# insert into t1 values ( 'snaga ＠ snaga.org', 0);
ERROR:  Cannot insert a duplicate key into unique index email_count_key
snaga=# insert into t1 values ( 'snaga ＠ snaga.org', 1);
INSERT 7327405 1
snaga=# insert into t1 values ( 'snaga ＠ snaga.org', 1);
ERROR:  Cannot insert a duplicate key into unique index email_count_key
snaga=# insert into t1 values ( 'snaga ＠ snaga.org', 2);
INSERT 7327407 1
snaga=# insert into t1 values ( 'snaga ＠ snaga.org', 2);
ERROR:  Cannot insert a duplicate key into unique index email_count_key
snaga=# insert into t1 values ( 'snaga ＠ snaga.org', 3);
ERROR:  ExecAppend: rejected due to CHECK constraint count_check
snaga=# 

-- 
NAGAYASU Satoshi <snaga ＠ snaga.org>



From tak ＠ hdt.co.jp  Sun May 18 12:03:21 2003
From: tak ＠ hdt.co.jp (Takeshi Miyakawa)
Date: Sun, 18 May 2003 12:03:21 +0900
Subject: [pgsql-jp: 29955] Re: 40万件有るデータから重複をさけて登録する
In-Reply-To: <000d01c31ce4$6157a180$0b01a8c0@tono>
References: <000d01c31ce4$6157a180$0b01a8c0@tono>
Message-ID: <3EC6F7F8.3000404@hdt.co.jp>

　みやかわ＠ホビー・データです。

k_matsui wrote:
>だいた40万件の応募が予想されるのですが、重複したメールアドレスでの
>再応募が出来ないようにしたいのです。この場合、どのような方法が
>簡単かつ、実用的でしょうか？尚、応募は3回に分けて行われ、1つの応募に
>対して1度、計3回のメールアドレスでの応募が可能なようにしたいのですが、
>tableは１つにまとめたいのです。
　ユーザに対して、入力時に重複メールアドレスを告知するのかどうかが問題です。
　告知しないのであれば、単純にリクエストをそのまま格納するテーブルを作っ
ておき、
リスクエストから重複するメールアドレスを取り除いて、最終的に「受理された
リクエスト」
のテーブルを作るようにします。
　告知する場合でも、Web上で即その場で告知するのか、登録されたメールアド
レスに
重複するリクエストがあったことをメールするのか、いろいろな方法があると思
います。

　想像するに、プレゼントの応募か何かを受理するWebアプリケーションのよう
ですから、
あまり堅苦しく考えず「重複があっても告知しない」という方針でよいのではな
いかと思う
のですが、いかがでしょうか。

　ついでに言わせてもらいますと、メールアドレスの有効性は検証しなくても良
いのです
か？　たとえばフリーメールの類でも良いのだとすると、重複するメールアドレ
スを弾く
ような試みは大して意味があるとも思えません（同一人物が多数のメールアドレ
スを持っ
ている可能性が出てきますから）。
　重複があろうとなかろうと、何件リクエストがあり、有効なリクエストは何件
だったかを
クライアントに報告することは重要だと思うので、重複をどの時点で弾くかを問
わず、
リクエストの履歴はすべて保存すべきだと僕は思います。




From matsui ＠ tono-k.jp  Sun May 18 13:57:23 2003
From: matsui ＠ tono-k.jp (k_matsui)
Date: Sun, 18 May 2003 13:57:23 +0900
Subject: [pgsql-jp: 29956] Re: 40万件有るデータから重複をさけて登録する
References: <000d01c31ce4$6157a180$0b01a8c0@tono> <20030518115449.4542068d.snaga@snaga.org>
Message-ID: <003c01c31cfa$d8463f70$0b01a8c0@tono>

永安様、どうもマツイと申します。
早速のアドバイスありがとうございます。

>   1.) count を 0 にして INSERT
>   2.) 1.)に失敗したら、count を 1 にして INSERT
>   3.) 2.)に失敗したら、count を 2 にして INSERT
>   4.) 3.)に失敗したら、4回目なのでエラー

大変すばらしいと思うのですが、これですと一つ問題があります。
応募期間を３回に分けて、各期間ごとに１度づつ計３回の応募が
可能としたいので、これですと期間に関係なく３回までの応募と
なってしまいます。

例えば、
select count(email) from t-1 where email=$oubomail group by email
とかで応募して来たメールアドレスがいくつあるか数えて、
php側で一度目の応募の時はメールアドレスが0個の時、二度目の
応募は、1個以下、三度目は２個以下の時に応募OKみたいな感じ
にしたらどうでしょうか？

なにぶん40万件というデータをあつかった事がないのですが、
これでは処理的に無理はありませんでしょうか？

よろしくお願い致します。



From matsui ＠ tono-k.jp  Sun May 18 14:03:34 2003
From: matsui ＠ tono-k.jp (k_matsui)
Date: Sun, 18 May 2003 14:03:34 +0900
Subject: [pgsql-jp: 29957] Re: 40万件有るデータから重複をさけて登録する
References: <000d01c31ce4$6157a180$0b01a8c0@tono> <3EC6F7F8.3000404@hdt.co.jp>
Message-ID: <003d01c31cfa$d85581b0$0b01a8c0@tono>

みやかわ＠ホビー・データ様、どうもマツイと申します。
早速のご助言ありがとうございます。

確かにみやかわ様のおっしゃる通りです。単純に重複メールアドレスを排除するので
はなく、いろいろやり方がありますね。クライアント側からそのように依頼されたの
で
その事しか頭にありませんでした。ちょっとクライアント側にいろいろなパターンが
ある
事、注意点等みやかわさんに指摘して頂いた事を相談してみようと思います。

ありがとうございました。

> 　ユーザに対して、入力時に重複メールアドレスを告知するのかどうかが問題で
す。
> 　告知しないのであれば、単純にリクエストをそのまま格納するテーブルを作っ
> ておき、
> リスクエストから重複するメールアドレスを取り除いて、最終的に「受理された
> リクエスト」
> のテーブルを作るようにします。
> 　告知する場合でも、Web上で即その場で告知するのか、登録されたメールアド
> レスに
> 重複するリクエストがあったことをメールするのか、いろいろな方法があると思
> います。
>
> 　想像するに、プレゼントの応募か何かを受理するWebアプリケーションのよう
> ですから、
> あまり堅苦しく考えず「重複があっても告知しない」という方針でよいのではな
> いかと思う
> のですが、いかがでしょうか。
>
> 　ついでに言わせてもらいますと、メールアドレスの有効性は検証しなくても良
> いのです
> か？　たとえばフリーメールの類でも良いのだとすると、重複するメールアドレ
> スを弾く
> ような試みは大して意味があるとも思えません（同一人物が多数のメールアドレ
> スを持っ
> ている可能性が出てきますから）。
> 　重複があろうとなかろうと、何件リクエストがあり、有効なリクエストは何件
> だったかを
> クライアントに報告することは重要だと思うので、重複をどの時点で弾くかを問
> わず、
> リクエストの履歴はすべて保存すべきだと僕は思います。
>
>
>
>
>
>




From snaga ＠ snaga.org  Sun May 18 14:31:28 2003
From: snaga ＠ snaga.org (Satoshi Nagayasu)
Date: Sun, 18 May 2003 14:31:28 +0900
Subject: [pgsql-jp: 29958] Re: 40万件有るデータから重複をさけて登録する
In-Reply-To: <003c01c31cfa$d8463f70$0b01a8c0@tono>
References: <000d01c31ce4$6157a180$0b01a8c0@tono>
	<20030518115449.4542068d.snaga@snaga.org>
	<003c01c31cfa$d8463f70$0b01a8c0@tono>
Message-ID: <20030518143128.66a9baf5.snaga@snaga.org>

永安です。

"k_matsui" <matsui ＠ tono-k.jp> wrote:
> >   1.) count を 0 にして INSERT
> >   2.) 1.)に失敗したら、count を 1 にして INSERT
> >   3.) 2.)に失敗したら、count を 2 にして INSERT
> >   4.) 3.)に失敗したら、4回目なのでエラー
> 
> 大変すばらしいと思うのですが、これですと一つ問題があります。
> 応募期間を３回に分けて、各期間ごとに１度づつ計３回の応募が
> 可能としたいので、これですと期間に関係なく３回までの応募と
> なってしまいます。

そしたら、count を periodとして、募集期間{0,1,2}の間は、
period を {0,1,2} に（プログラム内で）固定にすれば
いいのではないでしょうか？

ロジックとしては、

  1.) 募集期間 n においては、period を n にして INSERT
  2.) 1.)に失敗したら、(その期間内の)重複応募としてエラー

とすればいいと思います。

> 例えば、
> select count(email) from t-1 where email=$oubomail group by email
> とかで応募して来たメールアドレスがいくつあるか数えて、
> php側で一度目の応募の時はメールアドレスが0個の時、二度目の
> 応募は、1個以下、三度目は２個以下の時に応募OKみたいな感じ
> にしたらどうでしょうか？
> 
> なにぶん40万件というデータをあつかった事がないのですが、
> これでは処理的に無理はありませんでしょうか？

確たることは言えませんが、集約関数は使わない方が無難な気がします。
使わなくて済むなら。

-- 
NAGAYASU Satoshi <snaga ＠ snaga.org>



From ttaniguchi ＠ taniguchi-jp.org  Sun May 18 15:29:50 2003
From: ttaniguchi ＠ taniguchi-jp.org (Tadashi Taniguchi)
Date: Sun, 18 May 2003 15:29:50 +0900
Subject: [pgsql-jp: 29959] Re: 40万件有るデータから重複をさけて登録する
In-Reply-To: <003c01c31cfa$d8463f70$0b01a8c0@tono>
References: <003c01c31cfa$d8463f70$0b01a8c0@tono>
Message-ID: <200305180629.AA00096@windows01.taniguchi-jp.org>

谷口＠ＩＰ−Ｓです

>永安様、どうもマツイと申します。
>
>なにぶん40万件というデータをあつかった事がないのですが、
>これでは処理的に無理はありませんでしょうか？

　　どちらにしろ条件のPostgreSQLが古すぎるので　できるだけ最新の
　PostgreSQLを使用したほうが良いでしょう。
　　作り方にもよりますが40万件もありWeb系でリアルタイム処理を行う
　のであれば7.1系と7.3系では劇的な速度差がでると思います。

　　運用については毎回締め切り後の集計で良いと思います。（はがき
　の応募でも無効かどうかは受け取ってから決めますので・・・）

 --------------------------------------------------------------------------
  ＩＰ−Ｓ　Ｌｔｄ．　（ネットワーク構築、ＶｏＩＰ、対ウイルス導入）
  http://www.ip-s.jp/  　〒564-0051　大阪府吹田市豊津町４０−６
　電話: 06-6310-8774   FAX: 06-6310-8775  mail:ttaniguchi ＠ ip-s.jp
　　　　　　　　　　　　　　　　　　　谷口　忠史  


From mashiki ＠ yanah.com  Sun May 18 18:34:52 2003
From: mashiki ＠ yanah.com (Mashiki)
Date: Sun, 18 May 2003 18:34:52 +0900
Subject: [pgsql-jp: 29960] Re: 40万件有るデータから重複をさけて登録する
In-Reply-To: <003c01c31cfa$d8463f70$0b01a8c0@tono>
References: <003c01c31cfa$d8463f70$0b01a8c0@tono>
Message-ID: <B0C31D20BBC962mashiki@yanah.com>

　Mashikiです。

>応募期間を３回に分けて、各期間ごとに１度づつ計３回の応募が
>可能としたいので、これですと期間に関係なく３回までの応募と
>なってしまいます。

メールアドレスと、応募期間ID(イベントコードかな？)で主キーに
してみては？


From office.hase ＠ nifty.ne.jp  Sun May 18 19:11:29 2003
From: office.hase ＠ nifty.ne.jp (S.Hase)
Date: Sun, 18 May 2003 19:11:29 +0900
Subject: [pgsql-jp: 29961] Re: 40万件有るデー
Message-ID: <20030518191129.88b610a9.03813@nifty.ne.jp>

はせ です。

あと実体験からですが、メールアドレスは小文字に変換して
格納しておく方が無難かと思われます。
ユーザー入力のメールアドレスを尊重するのであれば、
応募チェック時あるいは集計時に小文字変換を行う必要があります。

NIFTY会員などは ABC12345 のようなアカウントのため、
しばしば大文字で入力する人が多いためです。

また、メールアドレスの更新はないと思われますので、
重複チェック用にメールアドレスにINDEX張っても良いのでは？
と思います。
そうしておけばチェック時のqueryコストはほとんど問題にならないです。
60万件弱の会員データでの経験です。

以上。


From matsui ＠ tono-k.jp  Sun May 18 22:50:29 2003
From: matsui ＠ tono-k.jp (k_matsui)
Date: Sun, 18 May 2003 22:50:29 +0900
Subject: [pgsql-jp: 29962] Re: 40万件有るデー
References: <20030518191129.88b610a9.03813@nifty.ne.jp>
Message-ID: <004401c31d44$795ceaa0$0b01a8c0@tono>

レスをつけて頂いた皆様、ありがとうございます。マツイです。
まとめての返信で失礼致します。

まず、重複処理は行わずに集計段階ではじくのか、
または応募時に重複処理を行ってDBにinsertするのかを確認してみます。
（個人的にはやはり集計段階のほうが良いような気もしますが）

で、重複処理を行う場合の方法ですが、みなさまのレスを参考にした結果、
create table t1 (
mail_id int,
mail_add text,
constraint cs1 primary key (mail_id,mail_add)
);

または、mail_addにindexを張って
select mail_add from t1 where mail_add = $oubomail
でプログラム側ではじく。

と、この２通りが良さそうなのですが、メリット、デメリットなど
有りますでしょうか？

>どちらにしろ条件のPostgreSQLが古すぎるので　できるだけ最新の
>PostgreSQLを使用したほうが良いでしょう。

そんなに速度的に違いがあるものなのでしょうか。
バージョンアップするように薦めてみます。
しかし、今回の件ではおそらく間に合わないと思います。

> あと実体験からですが、メールアドレスは小文字に変換して
> 格納しておく方が無難かと思われます。

まさにその通りですね。
ご忠告ありがとうございます。





From gontakun ＠ fish.co.jp  Sun May 18 23:21:41 2003
From: gontakun ＠ fish.co.jp (Chie)
Date: Sun, 18 May 2003 23:21:41 +0900
Subject: [pgsql-jp: 29963] Re: 40万件有るデー
In-Reply-To: <20030518191129.88b610a9.03813@nifty.ne.jp>
References: <20030518191129.88b610a9.03813@nifty.ne.jp>
Message-ID: <20030518232133.4C47.GONTAKUN@fish.co.jp>

Chie.M です。
話題がずれるのですが・・・

> あと実体験からですが、メールアドレスは小文字に変換して
> 格納しておく方が無難かと思われます。
> ユーザー入力のメールアドレスを尊重するのであれば、
> 応募チェック時あるいは集計時に小文字変換を行う必要があります。
> 
> NIFTY会員などは ABC12345 のようなアカウントのため、
> しばしば大文字で入力する人が多いためです。

私は「大文字」を使用したメールアドレスをもっています。

具体的に言うと、アカウントの部分が
　gontakun@〜
ではなく
　Gontakun@〜
となっています。

更に面倒なことに、Gontakun@〜というアドレスを使用している私とは
別の人が、gontakun@〜というメールアドレスを使用しておりまして
Gontakun@〜を小文字に変換したメールアドレスは、全て他人の所に
届いてしまい、大変ややこしい事になっています。

数年前に取得した、とあるプロバイダのメールアドレスなのですが、
一般的にはプログラム側で、小文字に変換される事が多いため、
かなり不便な思いをしています。

一番面倒なのが、何かに登録した場合の確認メールや、
パスワードを忘れた場合のパスワードメールが私以外の人に届いて
しまっているという事なんです。

そのプロバイダでは、現在は大文字の入ったメールアカウントは
作成していないそうです。

こういう少数派のための事を考える必要は無いかもしれませんが、
一応こういうアドレスが存在するという事も知っていただきたいと思い
メールしました。

-----------------------------
 From : Chie Masuko
　     gontakun ＠ fish.co.jp
-----------------------------



From ogino ＠ sic.co.jp  Mon May 19 08:23:42 2003
From: ogino ＠ sic.co.jp (Ogino)
Date: Mon, 19 May 2003 08:23:42 +0900
Subject: [pgsql-jp: 29964] Re: 特定の日本語を含むとエラー
In-Reply-To: <20030518.102517.74755121.t-ishii@sra.co.jp>
References: <20030518.102517.74755121.t-ishii@sra.co.jp>
Message-ID: <200305182321.IAA24542@asagao.sic.co.jp>

荻野です。

> 
> そりゃそうでしょう．テーブル名も列名も間違っていますから．

すみません。
これは記述ミスです。

> 
> ここ数年日本語正規表現に関する障害は見たことがありません．たまにバグレ
> ポートが出てきますが，すべて使い方が悪かったのが原因です．
> 
> おそらくinitdbするときに --no-locale オプションを付けていないのじゃな
> いですか?RedHat系は日本語のロケールデータベースが腐っているので，ロケー
> ルサポートを有効にして日本語を使うとまずまともに動きません．

initdbするときには、--no-localeオプションをつけて
実行しています。

ただ、
>RedHat系は日本語のロケールデータベースが腐っているので
ということは知らなかったので、
今後の参考にさせていただきたいと思います。

>徳家　様
回答ありがとうございます。
今後は、JDBCの円コーディングについても
記述するようにいたします。

以上




From sirius ＠ jp.fujitsu.com  Mon May 19 09:09:46 2003
From: sirius ＠ jp.fujitsu.com (Takao Kato)
Date: Mon, 19 May 2003 09:09:46 +0900
Subject: [pgsql-jp: 29965] Re: 40万件有るデータから重複をさけて登録する
In-Reply-To: <000d01c31ce4$6157a180$0b01a8c0@tono>
References: <000d01c31ce4$6157a180$0b01a8c0@tono>
Message-ID: <u3smrbssol.wl@lespaul.lantc.cs.fujitsu.co.jp>

加藤＠川崎です。

色々アイディアがでていますが、もう一つ。方針はそのままで、永安さんのア
イディアに方法を追加するものですが、時限カラムをテーブルに設置するのは
いかがでしょうか?

CREATE TABLE t1 (
  email text,
  counter integer,
  limit date default 'now'::date,

  constraint email_count_key primary key (email,count),
  constraint conut_check check(
    (count >= 0 and count count < 2) and
    ((count == 0 and limit between '2003-01-01' and '2003-01-14') or
     (count == 1 and limit between '2003-01-15' and '2003-01-29') or
     (count == 2 and limit between '2003-01-30' and '2003-02-12'))
  )
);

あとは、永安さんの書かれている方法でデータ挿入してやれば良いかと。ただ、
日付を定義してしまうと汎用性に乏しいものになりますので、その場限りの使
いきりテーブルになってしまいますが。^^; 

それでは
----
加藤＠川崎
お便りは kato ＠ lantc.cs.fujitsu.co.jp まで


From hara ＠ quest.co.jp  Mon May 19 09:54:28 2003
From: hara ＠ quest.co.jp (原　啓次)
Date: Mon, 19 May 2003 09:54:28 +0900
Subject: [pgsql-jp: 29966] Re: NOW()関数のJDBC  経由時の動作について
In-Reply-To: <20030515.220552.71088354.sugita@sra.co.jp>
References: <20030515211017.2CC6.HARA@quest.co.jp> <20030515.220552.71088354.sugita@sra.co.jp>
Message-ID: <20030519095144.BECC.HARA@quest.co.jp>

おせわさまです。
原です。

> ;;; 環境
> ;;; Redhat 7.3
> ;;; PostgreSQL 7.3.2
> ;;; Apache 1.3.27
> ;;; JDK 1.3.07
> ;;; Tomcat 4.1.24
> ;;; 
> ;;; 上記環境でServletによる開発を行っております。
> ;;; INSERT時にPostgreSQLのNOW()という関数を利用しています。
> ;;; この関数は同一トランザクションでは何回SELECTしても同じ時刻を示すとありました。
> ;;; そこで、クライアントからpsqlを利用し、beginでトランザクションを開始後に
> ;;; SELECT NOW();を複数回実行しました。
> ;;; 結果として同じ時刻を抽出していました。
> ;;; これは納得したのですが、ServletでWebより実行したケースでは、
> ;;; commitを発行してトランザクションを複数発生させているにもかかわらず
> ;;; 現在時刻より30分以上前の値を持ってきていました。
> ;;; トランザクションのほかに、JDBCのコネクションなど何か原因があるのでしょう
> ;;; か？
> 
>   アプリケーション側のミスの可能性がかなり高いです。全クエリーをサーバ側でモニ
> ターし、かつアプリケーション側のクエリーと処理を見直すのが先決と思えます。

回答ありがとうございます。
アプリケーション側を調べて原因を見つけたいと思います。

以上です。
----------------------------------------------
（株）クエスト 
e-ソリューション部 eプラットフォームグループ
原　啓次 hara ＠ quest.co.jp
〒108-0014 東京都港区芝4-11-1（CBC田町ビル 8F）
TEL 03-3453-1183 FAX 03-3453-1184
----------------------------------------------



From toshitaka.iso ＠ hp.com  Mon May 19 10:37:55 2003
From: toshitaka.iso ＠ hp.com (Iso, Toshitaka)
Date: Mon, 19 May 2003 10:37:55 +0900
Subject: [pgsql-jp: 29967] Clusterコマンドにおける影響について
Message-ID: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E0234066A@tkoexc02.asiapacific.cpqcorp.net>

いつもお世話になります。

Clusterコマンドについてお教えください。

あるテーブルに付与されているIndexに対して
CLUSTER INDEX名 ON TABLE名;

とやったところ、そのテーブルに付随していた
INDEX（Primary Key含む）、Trigger、GRANTした権限が削除
されてしまいました。

【PostgreSQLのVersion】
7.2.1

マニュアルを参照してみたところそれと思われる記述はなかったため、
ほかにどのような影響があるのかなど、よろしければお教えください。

以上です。


From ishikawa-t ＠ comtecc.net  Mon May 19 10:50:16 2003
From: ishikawa-t ＠ comtecc.net (Tatsuro Ishikawa)
Date: Mon, 19 May 2003 10:50:16 +0900
Subject: [pgsql-jp: 29968] Re: Clusterコマンドにおける影響について
In-Reply-To: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E0234066A@tkoexc02.asiapacific.cpqcorp.net>
References: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E0234066A@tkoexc02.asiapacific.cpqcorp.net>
Message-ID: <20030519104838.69B2.ISHIKAWA-T@comtecc.net>

石川と申します

On Mon, 19 May 2003 10:37:55 +0900
"Iso, Toshitaka" <toshitaka.iso ＠ hp.com> wrote:

> あるテーブルに付与されているIndexに対して
> CLUSTER INDEX名 ON TABLE名;
> 
> とやったところ、そのテーブルに付随していた
> INDEX（Primary Key含む）、Trigger、GRANTした権限が削除
> されてしまいました。
> 
> 【PostgreSQLのVersion】
> 7.2.1
> 
> マニュアルを参照してみたところそれと思われる記述はなかったため、
どのマニュアルを参照されましたか
下記のマニュアルには、記載されていますが・・・・
http://www.postgresql.jp/document/pg721doc/reference/sql-cluster.html



From toshitaka.iso ＠ hp.com  Mon May 19 11:02:35 2003
From: toshitaka.iso ＠ hp.com (Iso, Toshitaka)
Date: Mon, 19 May 2003 11:02:35 +0900
Subject: [pgsql-jp: 29969] Re: Clusterコマンドにおける影響について
Message-ID: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E0234066B@tkoexc02.asiapacific.cpqcorp.net>

石川さん。ご返答ありがとうございます。

> どのマニュアルを参照されましたか
> 下記のマニュアルには、記載されていますが・・・・
> http://www.postgresql.jp/document/pg721doc/reference/sql-cluster.html

あわわ。。補足までじっくり読んでいませんでした。
ご迷惑をおかけしました。。


-----Original Message-----
From: Tatsuro Ishikawa [mailto:ishikawa-t ＠ comtecc.net] 
Sent: Monday, May 19, 2003 10:50 AM
To: pgsql-jp ＠ ml.postgresql.jp
Subject: [pgsql-jp: 29968] Re: Clusterコマンドにおける影響について


石川と申します

On Mon, 19 May 2003 10:37:55 +0900
"Iso, Toshitaka" <toshitaka.iso ＠ hp.com> wrote:

> あるテーブルに付与されているIndexに対して
> CLUSTER INDEX名 ON TABLE名;
> 
> とやったところ、そのテーブルに付随していた
> INDEX（Primary Key含む）、Trigger、GRANTした権限が削除
> されてしまいました。
> 
> 【PostgreSQLのVersion】
> 7.2.1
> 
> マニュアルを参照してみたところそれと思われる記述はなかったため、
どのマニュアルを参照されましたか
下記のマニュアルには、記載されていますが・・・・
http://www.postgresql.jp/document/pg721doc/reference/sql-cluster.html



From sorako_y ＠ hotmail.com  Mon May 19 11:46:44 2003
From: sorako_y ＠ hotmail.com (sorako yamamoto)
Date: Mon, 19 May 2003 02:46:44 +0000
Subject: [pgsql-jp: 29970] 24:00を超えた場合の時刻表示方法について
Message-ID: <Law15-F889iyP6UR6g80002f870@hotmail.com>

こんにちは。
いつもお世話になっております m(_ _)m

現在、

work_date	,-- 出勤日付 -- YYYY/MM/DD HH:II:SS形式(時間部分は、00:00:00)
in_time	,-- 出勤時刻 -- YYYY/MM/DD HH:II:SS形式
out_time	,-- 退勤時刻 -- YYYY/MM/DD HH:II:SS形式


というカラムを持っているテーブルがあるのですが、
work_date = 2003/05/18 00:00:00
in_time   = 2003/05/18 09:00:00
out_time  = 2003/05/19 02:00:00

というデータが入っている場合、
in_time   = 2003/05/18 09:00:00
out_time  = 2003/05/18 26:00:00

としてビューを作成して、SELECTしてきたいと考えています。

どのようにすればよいでしょうか？
いつも初歩的な質問で恐縮ですが、アドバイスいただけるとうれしいです。
よろしくお願い致します。


やまもとそらこ。

_________________________________________________________________
キャリアアップを目指すあなたのナビゲーター MSN 就職・転職   
http://career.msn.co.jp/  



From naonuma ＠ ubiquitous.co.jp  Mon May 19 11:59:22 2003
From: naonuma ＠ ubiquitous.co.jp (Naomasa Numajiri)
Date: Mon, 19 May 2003 11:59:22 +0900
Subject: [pgsql-jp: 29971] Re: 24:00を超えた場合の時刻表示方法について
In-Reply-To: <Law15-F889iyP6UR6g80002f870@hotmail.com>
References: <Law15-F889iyP6UR6g80002f870@hotmail.com>
Message-ID: <20030519115429.1819.NAONUMA@ubiquitous.co.jp>

こんにちは、

On Mon, 19 May 2003 02:46:44 +0000
"sorako yamamoto" <sorako_y ＠ hotmail.com> wrote:

---snip---
; 
; というカラムを持っているテーブルがあるのですが、
; work_date = 2003/05/18 00:00:00
; in_time   = 2003/05/18 09:00:00
; out_time  = 2003/05/19 02:00:00
; 
; というデータが入っている場合、
; in_time   = 2003/05/18 09:00:00
; out_time  = 2003/05/18 26:00:00
; 

where句には使用せず、表示に使えればいいのなら
work_date = 2003/05/18 00:00:00(時刻形式)
in_time   = 2003/05/18 09:00:00(時刻形式)
out_time  = 2003/05/19 02:00:00(時刻形式)
in_time2  = 2003/05/18 09:00:00(文字列)
out_time2 = 2003/05/18 26:00:00(文字列)
と、それぞれのデータ型を考えればいいのではないでしょうか？

「26」時は、日付をチェックして「24＋2」すればいいと思います。

参考になれば

--ぬ



From hayakawa ＠ sam.hi-ho.ne.jp  Mon May 19 13:01:45 2003
From: hayakawa ＠ sam.hi-ho.ne.jp (HAYAKAWA Hiroshi)
Date: Mon, 19 May 2003 13:01:45 +0900
Subject: [pgsql-jp: 29972] oid	の同一性と生成ロジックについて
Message-ID: <BAEE8639.22D33%hayakawa@sam.hi-ho.ne.jp>

早川＠名古屋です。

「WEB+DB PRESS」の最新号vol.14の
特集３「PostgreSQLへのレプリケーション導入法」
を読んでいてふと疑問に思ったことがあります。

この記事自体はPGReplicateを中心としたもので、
その作者の方が書かれていますが、その記事の中で、

〜〜〜
クエリーベースのレプリケーションでは
OIDや現在時刻取得関数などはレプリケーションできないという制限がある
これはUsogres（うそぐれす）でも同様
〜〜〜

という主旨の記述がありました。
つまりそれらは使用できないということだと理解したのですが、
いまUsogresを利用していてoidも使っちゃっています。
これまで障害が発生したことはないのですが、
（ただし使い方はヘビーではないです）
ちょっと不安になって情報を探してみたものの
oidの使用不可について言及されたものがみつかりませんでした。

つまるところ、PostgreSQLにおいて
initdb以降同一のクエリーを同じ順に実行した場合に、
oidが同一であることがoidの生成ロジック的に保証されていれば
実質的な問題は発生しない、と言えると思うのですが、
いかがなものなのでしょうか。


ちなみに、いまは、ウェブアプリケーションにおいて、
新規データの登録時に、INSERTの後にoidを取得し、
そのoidを用いてそのデータのシリアルなIDを取得する、
というロジックを多用しています。

もし上記のことが保証されていなければ
このロジックは使えないですよね？


-----
With your dreaming, with your smile.
Hayakawa, Hiroshi <hayakawa ＠ sam.hi-ho.ne.jp>
Nagoya,Aichi,JAPAN ☆彡



From rym ＠ 7star.net  Mon May 19 13:21:09 2003
From: rym ＠ 7star.net (T.MURAKAMI)
Date: Mon, 19 May 2003 13:21:09 +0900
Subject: [pgsql-jp: 29973] Re: oid の同一性と生成ロジックについて
In-Reply-To: <BAEE8639.22D33%hayakawa@sam.hi-ho.ne.jp>
Message-ID: <5.0.2.7.2.20030519130917.01e3a5b8@mail.7star.net>

ぴょンです。久しぶりの書き込みです。

Usogresを使用したことはないですが、いろいろ読んでますので書きます。

プログラム側からするとUsogresは接続されているデータベースのwrapperになりますから、データベースの内部の事情(oid)など知ったことではないと思います。
Usogresが関数などを解釈して、どちらかのデータベースに実行させたあとその結果を両方に書き込むなどの処理を行っているのであれば別ですが…。

ミラーリングしてる2台のハードディスクに全く同じ物理的なブロックを利用することを期待するようなものだと思います。


ちょい自信なし。





From sorako_y ＠ hotmail.com  Mon May 19 13:30:37 2003
From: sorako_y ＠ hotmail.com (sorako yamamoto)
Date: Mon, 19 May 2003 04:30:37 +0000
Subject: [pgsql-jp: 29974] Re: 24:00を超えた場合の時刻表示方法について
Message-ID: <Law15-F80s4KWiGtXsL0001c852@hotmail.com>

お世話になります。ご回答ありがとうございます。

>where句には使用せず、表示に使えればいいのなら
>work_date = 2003/05/18 00:00:00(時刻形式)
>in_time   = 2003/05/18 09:00:00(時刻形式)
>out_time  = 2003/05/19 02:00:00(時刻形式)
>in_time2  = 2003/05/18 09:00:00(文字列)
>out_time2 = 2003/05/18 26:00:00(文字列)
>と、それぞれのデータ型を考えればいいのではないでしょうか？
>

表示用のカラムを作成するということですよね？

>「26」時は、日付をチェックして「24＋2」すればいいと思います。

if( to_char( work_date , 'YYYY/MM/DD') != to_char( in_time , 'YYYY/MM/DD') 
)	-- 「24＋2」する…
else -- そのまま…


ということですよね？
考え方は分かるのですが、SQLの方がさっぱり…
Select文の書き方について、もう少しご助言ください。

すみません…よろしくお願い致します。


やまもとそらこ。

_________________________________________________________________
今が旬のクルマを徹底的に分析します MSN 自動車   http://car.msn.co.jp/  



From hayakawa ＠ sam.hi-ho.ne.jp  Mon May 19 13:37:09 2003
From: hayakawa ＠ sam.hi-ho.ne.jp (HAYAKAWA Hiroshi)
Date: Mon, 19 May 2003 13:37:09 +0900
Subject: [pgsql-jp: 29975] Re: oid の同一性と生成ロジックについて
In-Reply-To: <5.0.2.7.2.20030519130917.01e3a5b8@mail.7star.net>
Message-ID: <BAEE8E85.22D40%hayakawa@sam.hi-ho.ne.jp>

早川＠名古屋です。

on 03.5.19 1:21 PM, T.MURAKAMI at rym ＠ 7star.net wrote:

> ぴょンです。久しぶりの書き込みです。
> 
> Usogresを使用したことはないですが、いろいろ読んでますので書きます。
> 
> プログラム側からするとUsogresは接続されているデータベースのwrapperになりますか
> ら、データベースの内部の事情(oid)など知ったことではないと思います。

はい。
Usogresはクエリー実行時にoidを同一にすることを保証し（でき）ませんが、
（select時に異なっていればエラーになったんじゃなかったかと思います）
PostgreSQLがinitdb以降、
例えば1から順にoidを発行するといったロジックになっているのであれば
実際的にはUsogres使用時にoidの同一性は保たれるのではないか、
という風に思うのです。

しかしもしoidがランダム性のあるロジックで生成されているのであれば
すでに異常が起きていても不思議はないと思うのですが、
手元の環境ではいまのところそれはないようなのです。


-----
With your dreaming, with your smile.
Hayakawa, Hiroshi <hayakawa ＠ sam.hi-ho.ne.jp>
Nagoya,Aichi,JAPAN ☆彡



From yutaka ＠ hi-net.zaq.ne.jp  Mon May 19 13:47:07 2003
From: yutaka ＠ hi-net.zaq.ne.jp (Yutaka tanida)
Date: Mon, 19 May 2003 13:47:07 +0900
Subject: [pgsql-jp: 29976] Re: oid の同一性と生成ロジックについて
In-Reply-To: <BAEE8639.22D33%hayakawa@sam.hi-ho.ne.jp>
References: <BAEE8639.22D33%hayakawa@sam.hi-ho.ne.jp>
Message-ID: <20030519133711.DB3D.YUTAKA@hi-net.zaq.ne.jp>

谷田です。

On 19 May 2003 13:03:28 +0900
HAYAKAWA Hiroshi <hayakawa ＠ sam.hi-ho.ne.jp> wrote:

> つまるところ、PostgreSQLにおいて
> initdb以降同一のクエリーを同じ順に実行した場合に、
> oidが同一であることがoidの生成ロジック的に保証されていれば
> 実質的な問題は発生しない、と言えると思うのですが、
> いかがなものなのでしょうか。

保証はされていないと思いますが、現状ではほぼそのように動作します。

むしろ、同じ順に実行していると保証することの方が大変で、それを保証できな
いからこそ、この記事の作者（読んでないけど三谷さん？）は「レプリケーショ
ンできない」と書いているのだと思います。

> ちなみに、いまは、ウェブアプリケーションにおいて、
> 新規データの登録時に、INSERTの後にoidを取得し、
> そのoidを用いてそのデータのシリアルなIDを取得する、
> というロジックを多用しています。

そもそも、そのロジックがあまりよろしくないと思います。この場合のID取得に
はcurrval()関数を使うとか、serial型を使わずに自前でsequence管理するのが
筋でしょう。

-- 
Yutaka tanida <yutaka ＠ nonsensecorner.com>
http://www.nonsensecorner.com/



From rym ＠ 7star.net  Mon May 19 14:04:43 2003
From: rym ＠ 7star.net (T.MURAKAMI)
Date: Mon, 19 May 2003 14:04:43 +0900
Subject: [pgsql-jp: 29977] Re: oid の同一性と生成ロジックについて
In-Reply-To: <20030519133711.DB3D.YUTAKA@hi-net.zaq.ne.jp>
References: <BAEE8639.22D33%hayakawa@sam.hi-ho.ne.jp>
 <BAEE8639.22D33%hayakawa@sam.hi-ho.ne.jp>
Message-ID: <5.0.2.7.2.20030519135335.034c0ec8@mail.7star.net>

ぴょンです。

>> つまるところ、PostgreSQLにおいて
>> initdb以降同一のクエリーを同じ順に実行した場合に、
>> oidが同一であることがoidの生成ロジック的に保証されていれば
>> 実質的な問題は発生しない、と言えると思うのですが、
>> いかがなものなのでしょうか。
>
>保証はされていないと思いますが、現状ではほぼそのように動作します。

今後の実装で保証されるわけではないのですし。

>むしろ、同じ順に実行していると保証することの方が大変で、それを保証できな
>いからこそ、この記事の作者（読んでないけど三谷さん？）は「レプリケーショ
>ンできない」と書いているのだと思います。

クエリ内で日付をインサートしたらレプリケーションごとに入っている時間が違ってたなんてのはシャレにならないですよね。
今度こそselectでエラーが起きてしまいます。

>> ちなみに、いまは、ウェブアプリケーションにおいて、
>> 新規データの登録時に、INSERTの後にoidを取得し、
>> そのoidを用いてそのデータのシリアルなIDを取得する、
>> というロジックを多用しています。
>
>そもそも、そのロジックがあまりよろしくないと思います。この場合のID取得に
>はcurrval()関数を使うとか、serial型を使わずに自前でsequence管理するのが
>筋でしょう。

もちろんトリガーなしで、プログラムのロジックとして書くべきでしょう。






From yutaka ＠ hi-net.zaq.ne.jp  Mon May 19 14:34:29 2003
From: yutaka ＠ hi-net.zaq.ne.jp (Yutaka tanida)
Date: Mon, 19 May 2003 14:34:29 +0900
Subject: [pgsql-jp: 29978] Re: oid の同一性と生成ロジックについて
In-Reply-To: <5.0.2.7.2.20030519135335.034c0ec8@mail.7star.net>
References: <20030519133711.DB3D.YUTAKA@hi-net.zaq.ne.jp> <5.0.2.7.2.20030519135335.034c0ec8@mail.7star.net>
Message-ID: <20030519142050.DB43.YUTAKA@hi-net.zaq.ne.jp>

谷田です。

On 19 May 2003 14:05:26 +0900
"T.MURAKAMI" <rym ＠ 7star.net> wrote:

> >保証はされていないと思いますが、現状ではほぼそのように動作します。
> 今後の実装で保証されるわけではないのですし。

保証はされていませんが、現状についてはそれで十分でしょう。だからといって
推奨される使い方ではありません。

> クエリ内で日付をインサートしたらレプリケーションごとに入っている時間が違ってたなんてのはシャレにならないですよね。

だから、それがクエリベースのレプリケーションの欠点であり、最初の記事はそ
れを指摘しているのです。

-- 
Yutaka tanida <yutaka ＠ nonsensecorner.com>
http://www.nonsensecorner.com/



From naonuma ＠ ubiquitous.co.jp  Mon May 19 14:28:18 2003
From: naonuma ＠ ubiquitous.co.jp (Naomasa Numajiri)
Date: Mon, 19 May 2003 14:28:18 +0900
Subject: [pgsql-jp: 29979] Re: 24:00を超えた場合の時刻表示方法について
In-Reply-To: <Law15-F80s4KWiGtXsL0001c852@hotmail.com>
References: <Law15-F80s4KWiGtXsL0001c852@hotmail.com>
Message-ID: <20030519133111.182E.NAONUMA@ubiquitous.co.jp>

こんにちは、

On Mon, 19 May 2003 04:30:37 +0000
"sorako yamamoto" <sorako_y ＠ hotmail.com> wrote:

; お世話になります。ご回答ありがとうございます。
; 
---snip---
; 
; 表示用のカラムを作成するということですよね？
; 
; >「26」時は、日付をチェックして「24＋2」すればいいと思います。
; 
; if( to_char( work_date , 'YYYY/MM/DD') != to_char( in_time , 'YYYY/MM/DD') 
; )	-- 「24＋2」する…
; else -- そのまま…
; 
; 
; ということですよね？
; 考え方は分かるのですが、SQLの方がさっぱり…
; Select文の書き方について、もう少しご助言ください。
; 

---snip---

PHPのML([PHP-users 15364])での意見ですが、僕も「魚を
与えるよりも、釣りの仕方を教える」方針でいきます。

以下の方法を提案します
1) PostgreSQLリファレンスより、SELECT文の書き方や、PostgreSQL提供の
   SQL関数を確認する。
2) 自分なりにSELECT文を作成する
	-- うまく行ったら、それでCreate Viewして終わり
3) 「どのような理解で、そのSELECT文を作成し、自分の予想とどのように
   違うのか？」の情報といっしょに、もう一度質問する。

では、がんばってください。

p.s.
PostgreSQLで解決することにこだわらず、PHPなどのWEBアプリケーション
の表示側で解決してもいいじゃないでしょうか？
トリガーで、データの登録/更新の時にやってしまうという手もあります。

--ぬ＠回答よりもいずれ独力で解決できるように


From sirius ＠ jp.fujitsu.com  Mon May 19 14:56:08 2003
From: sirius ＠ jp.fujitsu.com (Takao Kato)
Date: Mon, 19 May 2003 14:56:08 +0900
Subject: [pgsql-jp: 29980] Re: 24:00を超えた場合の時刻表示方法について
In-Reply-To: <20030519133111.182E.NAONUMA@ubiquitous.co.jp>
References: <Law15-F80s4KWiGtXsL0001c852@hotmail.com>
	<20030519133111.182E.NAONUMA@ubiquitous.co.jp>
Message-ID: <u3iss7scnb.wl@lespaul.lantc.cs.fujitsu.co.jp>

加藤＠川崎です。

> PHPのML([PHP-users 15364])での意見ですが、僕も「魚を
> 与えるよりも、釣りの仕方を教える」方針でいきます。

うっ、答え書いて出しかけてしまいました ^^;
# もったいないけれど出さないでおきます。

> 以下の方法を提案します
> 1) PostgreSQLリファレンスより、SELECT文の書き方や、PostgreSQL提供の
>    SQL関数を確認する。

それだけだと難しいかもしれないので、ヒント(ポインター)をいくつか。

ヒント1:case when 〜 else 〜 end
ヒント2:to_char
ヒント3:int または text型へのキャスト
ヒント4:文字列連結関数(?)


それと、日付を比較するのに

>if( to_char( work_date , 'YYYY/MM/DD') != to_char( in_time , 'YYYY/MM/DD') 
>)	-- 「24＋2」する…
>else -- そのまま…

とされていますが、例えばヒント3の「キャスト」を利用して、

if(in_time::date != out_time::date)  -- 「24+2」の処理
else                                 --  そのまま

とやったりできますよね。今回はtimestampをdateにキャストしていますが、、、、

ちょっと考えるとパズルが解けたように答えが閃くかと。
-------------
加藤＠川崎


From sorako_y ＠ hotmail.com  Mon May 19 16:04:38 2003
From: sorako_y ＠ hotmail.com (sorako yamamoto)
Date: Mon, 19 May 2003 07:04:38 +0000
Subject: [pgsql-jp: 29981] Re: 24:00を超えた場合の時刻表示方法について
Message-ID: <Law15-F41qy9kGWicZ700030147@hotmail.com>

どうもです。

加藤さんにアドバイスいただいた通り、

>ヒント1:case when 〜 else 〜 end
>ヒント2:to_char
>ヒント3:int または text型へのキャスト
>ヒント4:文字列連結関数(?)


SELECT 
  out_time, 
  work_date , 
  CASE WHEN 
    work_date::date != out_time::date THEN 
      -- 「24+2」の処理  
   END  
     FROM test ;


までは、どうにかできたのですが、（というかそのまま…）
-- 「24+2」の処理  
to_char( out_time , 'HH+24:MI' )のようなことはできないのですね…
結果:02+24:00　(苦笑)

out_time::int後、hh部とmm部に分け、hh+24後、文字列に直す。
という感じですよね。


viewを使ってセレクトしてきた方が早いかな〜と思っていたのですが、

>PostgreSQLで解決することにこだわらず、PHPなどのWEBアプリケーション
>の表示側で解決してもいいじゃないでしょうか？

phpのアプリ側で対応して、もう一度SQL文を勉強しなおします。


すみませんでした。ありがとうございました。

_________________________________________________________________
会員登録は無料  充実した出品アイテムなら MSN オークション   
http://auction.msn.co.jp/  



From sirius ＠ jp.fujitsu.com  Mon May 19 16:28:53 2003
From: sirius ＠ jp.fujitsu.com (Takao Kato)
Date: Mon, 19 May 2003 16:28:53 +0900
Subject: [pgsql-jp: 29982] Re: 24:00を超えた場合の時刻表示方法について
In-Reply-To: <Law15-F41qy9kGWicZ700030147@hotmail.com>
References: <Law15-F41qy9kGWicZ700030147@hotmail.com>
Message-ID: <u3fznbs8cq.wl@lespaul.lantc.cs.fujitsu.co.jp>

 加藤＠川崎です。

> -- 「24+2」の処理  
> to_char( out_time , 'HH+24:MI' )のようなことはできないのですね…
> 結果:02+24:00　(苦笑)
> out_time::int後、hh部とmm部に分け、hh+24後、文字列に直す。
> という感じですよね。

おっし〜い。ヒント3の部分をout_time全体ではなく、対象部分だけに適用す
れば答えは求められると思います。つまり『text』の「数字部分」の足し算は
無理でも『int』なら、、、、で、対象部分を取り出すのにヒント2がやってき
ます。


で、抽出した『日付』と、out_timeの『分と秒』部分の『各文字列』と、結果
をヒント4の文字列連結するば答えになると思います。ヒント4は

   http://osb.sra.co.jp/PostgreSQL/Manual/cgi-bin/namazu.cgi

で、「文字列」と「連結」で検索するとでてきます。

ヒント出し過ぎかな?
# まぁ、これが最適解かと言われると疑問ですが ^^;
-----------
加藤＠川崎


From sorako_y ＠ hotmail.com  Mon May 19 16:48:29 2003
From: sorako_y ＠ hotmail.com (sorako yamamoto)
Date: Mon, 19 May 2003 07:48:29 +0000
Subject: [pgsql-jp: 29983] Re: 24:00を超えた場合の時刻表示方法について
Message-ID: <Law15-F10SesSrM6ytu000300ce@hotmail.com>

>ヒント3の部分をout_time全体ではなく、対象部分だけに適用す
>れば答えは求められると思います。

SELECT 
  out_time, 
  work_date , 
  CASE WHEN 
    work_date::date != out_time::date THEN 
	( (to_char( out_time , 'HH24'))::int + 24 )  || ':' || ( to_char( out_time 
, 'MI') )
   END  
     FROM test ;

としたところ、無事結果を表示することができました！

>ヒント出し過ぎかな?
ヒントがなかったらできなかったです！
どうも、ありがとうございます。

_________________________________________________________________
自宅の PC で英語力をアップ MSN 英会話   http://englishtown.msn.co.jp/  



From iakio ＠ pjam.jpweb.net  Mon May 19 16:51:43 2003
From: iakio ＠ pjam.jpweb.net (ISHIDA Akio)
Date: Mon, 19 May 2003 16:51:43 +0900
Subject: [pgsql-jp: 29984] Re: 24:00を超えた場合の時刻表示方法について
In-Reply-To: <Law15-F10SesSrM6ytu000300ce@hotmail.com>
References: <Law15-F10SesSrM6ytu000300ce@hotmail.com>
Message-ID: <20030519165143.C3C9E400.iakio@pjam.jpweb.net>

石田@苫小牧市です。
# のりおくれてしまったようですが。

出勤/退勤時刻ということなので、会社に2泊してしまった
人のために別解です。

select to_char(in_time, 'YYYY/MM/DD ')
    ||  date_part('hour', in_time)
        + date_part('epoch', out_time - in_time) / 3600
    || to_char(in_time, ':MI:SS')
       from test;



"sorako yamamoto" <sorako_y ＠ hotmail.com> wrote:
(2003/05/19 16:48)

> >ヒント3の部分をout_time全体ではなく、対象部分だけに適用す
> >れば答えは求められると思います。
> 
> SELECT 
>   out_time, 
>   work_date , 
>   CASE WHEN 
>     work_date::date != out_time::date THEN 
> 	( (to_char( out_time , 'HH24'))::int + 24 )  || ':' || ( to_char( out_time 
> , 'MI') )
>    END  
>      FROM test ;
> 
> としたところ、無事結果を表示することができました！
> 
> >ヒント出し過ぎかな?
> ヒントがなかったらできなかったです！
> どうも、ありがとうございます。
> 
> _________________________________________________________________
> 自宅の PC で英語力をアップ MSN 英会話   http://englishtown.msn.co.jp/  

--
ISHIDA Akio<iakio ＠ pjam.jpweb.net>



From office.hase ＠ nifty.ne.jp  Mon May 19 17:01:37 2003
From: office.hase ＠ nifty.ne.jp (S.Hase)
Date: Mon, 19 May 2003 17:01:37 +0900
Subject: [pgsql-jp: 29985] Re: 24:00を超えた
Message-ID: <20030519170137.88b610a9.20669@nifty.ne.jp>

はせ です。

> p.s.
> PostgreSQLで解決することにこだわらず、PHPなどのWEBアプリケーション
> の表示側で解決してもいいじゃないでしょうか？
> トリガーで、データの登録/更新の時にやってしまうという手もあります。
> 
> --ぬ＠回答よりもいずれ独力で解決できるように

--ぬ さんの考えに賛成です。
WEBアプリとSQLの使い分けをお奨めします。
私の場合、
・RDBMS上は必要最小限の正確（クリーン）なデータを格納
・SQLでは、対象データの抽出・集計・日付（期間）の計算
・WEBアプリ(PHP)で、表示形式の編集
という感じで、ざっくり切り分けています。
将来RDBMSを変えた場合などのことを考えて、あまりPostgreSQLに依存した
アプリにしないようにしています。（ご参考まで）

ご自分なりに方針をじっくり検討し、その上で必要なテクニックを
習得されるのが吉かと。


From iakio ＠ pjam.jpweb.net  Mon May 19 17:25:53 2003
From: iakio ＠ pjam.jpweb.net (ISHIDA Akio)
Date: Mon, 19 May 2003 17:25:53 +0900
Subject: [pgsql-jp: 29986] Re: 24:00を超えた場合の時刻表示方法について
In-Reply-To: <20030519165143.C3C9E400.iakio@pjam.jpweb.net>
References: <Law15-F10SesSrM6ytu000300ce@hotmail.com> <20030519165143.C3C9E400.iakio@pjam.jpweb.net>
Message-ID: <20030519172553.E7B6FD58.iakio@pjam.jpweb.net>

石田@苫小牧市です。まちがってました。^^;;

ISHIDA Akio <iakio ＠ pjam.jpweb.net> wrote:
(2003/05/19 16:51)

> 石田@苫小牧市です。
> # のりおくれてしまったようですが。
> 
> 出勤/退勤時刻ということなので、会社に2泊してしまった
> 人のために別解です。
> 
> select to_char(in_time, 'YYYY/MM/DD ')
>     ||  date_part('hour', in_time)
>         + date_part('epoch', out_time - in_time) / 3600
>     || to_char(in_time, ':MI:SS')
>        from test;

select to_char(in_time, 'YYYY/MM/DD ')
    || (date_part('hour', in_time)
        + date_part('hour', out_time - in_time))
    || to_char(out_time - in_time, ':MI:SS')
       from t;

でした。ところで、

> "sorako yamamoto" <sorako_y ＠ hotmail.com> wrote:
> (2003/05/19 16:48)
> 
> > >ヒント3の部分をout_time全体ではなく、対象部分だけに適用す
> > >れば答えは求められると思います。
> > 
> > SELECT 
> >   out_time, 
> >   work_date , 
> >   CASE WHEN 
> >     work_date::date != out_time::date THEN 
> > 	( (to_char( out_time , 'HH24'))::int + 24 )  || ':' || ( to_char( out_time 
> > , 'MI') )
> >    END  
> >      FROM test ;

これも、in_time が 00 分以外のときはまずそうですね。

( (to_char( out_time , 'HH24'))::int + 24 ) || ':' ||
 ( to_char( out_time  - in_time, 'MI') )
                        ^^^^^^^ 
とかしないとまずそうですね。

--
ISHIDA Akio<iakio ＠ pjam.jpweb.net>



From sirius ＠ jp.fujitsu.com  Mon May 19 17:44:30 2003
From: sirius ＠ jp.fujitsu.com (Takao Kato)
Date: Mon, 19 May 2003 17:44:30 +0900
Subject: [pgsql-jp: 29987] Re: 24:00を超えた場合の時刻表示方法について
In-Reply-To: <20030519172553.E7B6FD58.iakio@pjam.jpweb.net>
References: <Law15-F10SesSrM6ytu000300ce@hotmail.com>
	<20030519165143.C3C9E400.iakio@pjam.jpweb.net>
	<20030519172553.E7B6FD58.iakio@pjam.jpweb.net>
Message-ID: <u3addjs4up.wl@lespaul.lantc.cs.fujitsu.co.jp>

加藤＠川崎です。

綺麗に片付けてくれてありがとうございました > 石田さん
# if〜で書いていたから比較演算で処理することしか考えてませんでした。

> ところで、
> 
> これも、in_time が 00 分以外のときはまずそうですね。

大丈夫だと思いますよ。欲しいがってたのは24時を越えた時の「時」部分を積
算した「退勤時刻」ですから。勤務時間算出だとまずいですけど(汗)

勤務時間そのものなら

  (out_time - in_time)::time  -- 当然失敗します。念のため

みたいな処理が必要ですね。


それよりも退勤時刻が24時越えしていない場合にそのまま out_time を出す必
要があるのに、出していないのが問題だと思ったりします。
----
加藤＠川崎


From mitani ＠ sraw.co.jp  Mon May 19 17:52:19 2003
From: mitani ＠ sraw.co.jp (mitani)
Date: Mon, 19 May 2003 17:52:19 +0900
Subject: [pgsql-jp: 29988] Re: oid の同一性と生成ロジックについて
In-Reply-To: <20030519142050.DB43.YUTAKA@hi-net.zaq.ne.jp>
References: <5.0.2.7.2.20030519135335.034c0ec8@mail.7star.net> <20030519142050.DB43.YUTAKA@hi-net.zaq.ne.jp>
Message-ID: <20030519174732.0340.MITANI@sraw.co.jp>

三谷＠広島です．

谷田さん，フォローありがとうございました．
> > >保証はされていないと思いますが、現状ではほぼそのように動作します。
> > 今後の実装で保証されるわけではないのですし。
> 
> 保証はされていませんが、現状についてはそれで十分でしょう。だからといって
> 推奨される使い方ではありません。
そうですね．OIDは色々問題がありますので，IDの代わりに使うのはお勧めでき
ません．
> 
> > クエリ内で日付をインサートしたらレプリケーションごとに入っている時間が違ってたなんてのはシャレにならないですよね。
> 
> だから、それがクエリベースのレプリケーションの欠点であり、最初の記事はそ
> れを指摘しているのです。
これもその通りでして，クエリーベースのレプリケーションではnow()のような
ものをINSERTされても，その値を全部のDBで整合性を保障できないのです．

とはいえ，このままでは制限が多いので，時刻関数については，レプリケーショ
ンサーバの時刻をマスターとしたような関数を用意しようと考えています．


=============================
三谷　篤<mitani ＠ sraw.co.jp>
=============================





From sorako_y ＠ hotmail.com  Mon May 19 18:46:21 2003
From: sorako_y ＠ hotmail.com (sorako yamamoto)
Date: Mon, 19 May 2003 09:46:21 +0000
Subject: [pgsql-jp: 29989] Re: 24:00を超えた場合の時刻表示方法について
Message-ID: <Law15-F81itJyMmxsyw000308e6@hotmail.com>

石田さん、加藤さんご回答の程どうもありがとうございました。


>それよりも退勤時刻が24時越えしていない場合にそのまま out_time を出す必
>要があるのに、出していないのが問題だと思ったりします。

ELSE でちゃんと処理しようと思います。


Numajiriさん、はせさんのご意見も参考に
どの層でどの処理を行うのか、きちんと考えていきたいと思います。

>WEBアプリとSQLの使い分けをお奨めします。
>私の場合、
>・RDBMS上は必要最小限の正確（クリーン）なデータを格納
>・SQLでは、対象データの抽出・集計・日付（期間）の計算
>・WEBアプリ(PHP)で、表示形式の編集
>という感じで、ざっくり切り分けています。
>将来RDBMSを変えた場合などのことを考えて、あまりPostgreSQLに依存した
>アプリにしないようにしています。（ご参考まで）

>ご自分なりに方針をじっくり検討し、その上で必要なテクニックを
>習得されるのが吉かと。

アドバイスくださった方々どうもありがとうございました。

やまもとそらこ。

_________________________________________________________________
最新のファイナンス情報とライフプランのアドバイス MSN マネー  
http://money.msn.co.jp/  



From t_suzuki ＠ kenwood-eng.co.jp  Mon May 19 18:56:19 2003
From: t_suzuki ＠ kenwood-eng.co.jp (T.Suzuki)
Date: Mon, 19 May 2003 18:56:19 +0900
Subject: [pgsql-jp: 29990] Re: 24:00を超えた場合の時刻表示方法について
References: <Law15-F10SesSrM6ytu000300ce@hotmail.com><20030519165143.C3C9E400.iakio@pjam.jpweb.net><20030519172553.E7B6FD58.iakio@pjam.jpweb.net> <u3addjs4up.wl@lespaul.lantc.cs.fujitsu.co.jp>
Message-ID: <00ac01c31dec$e59bdbb0$1e9316ac@sys010>

鈴木と申します。

既に石田さんが、大変参考になるSQLを紹介されている上、
ご本人が解決されているので、邪魔でしかないかも知れませんが。。

> viewを使ってセレクトしてきた方が早いかな〜と思っていたのですが、
>
> >PostgreSQLで解決することにこだわらず、PHPなどのWEBアプリケーション
> >の表示側で解決してもいいじゃないでしょうか？
>
> phpのアプリ側で対応して、もう一度SQL文を勉強しなおします。

勤怠管理系の処理である場合、勤怠上の日付が変わるのは、
６時とか７時である為、その扱い(変換処理)にかなり苦労しました。

　・日付を超えて、「在場時間 = 退勤時間 - 出勤時間」をSQLで行いたい
　・「在場時間から休憩時間を減算」をSQLで行いたい

こういった処理を、（6時とか7時とか）基準時間をもとに計算したかったので、
時刻←→Int時間の変換を、PL/pgSQLで関数化してみました。

> phpのアプリ側で対応して　〜略
psqlから、ちょっとしたSQLを投げる際に、PHPのクラスでは使えなくて
思い切って作りました。

以下に、そのPL/ｐｇSQLを紹介させて下さい。
#サーバに掲載してリンクを張りたい所ですが、場所が無い為、
#メールにて紹介させて下さい。
----------------------------------------------------
/**
 * TO_INTERVAL()
 * 時刻形式の表現を引数に受け取り、基準時間からの経過分を返します。
 * ※プロシージャ作成時に基準時刻(root_time)を変更しておく必要があります。
 *
 * @language     plpgsql
 * @date         2001/11/14
 * @author       t_suzuki
 * @param        text     ":"区切りの時刻表現された文字列
 * @return       integer  基準時間からの経過時間を分単位で表した数値
 */
CREATE or REPLACE FUNCTION to_interval(text)
RETURNS integer AS '
Declare
    ins_text alias for $1;                          --引数の別名定義
    root_time constant integer not null default 7;  --開始基準時刻
    center          integer;    --引数内の文字列で、「：」の位置
    total_time      integer;    --合計値（分）【戻り値】
    houre_time      integer;    --時間単位部分
    minute_time     integer;    --分単位部分
Begin
    --引数の文字列で「：」の位置を調べる
    center := position('':'' in ins_text);
    IF center < 1 THEN          --「：」が無い
        RETURN NULL;            --「：」が無い場合は、NULL値を返す
    END IF;
    IF character_length(ins_text) <= center+1 THEN
      --分が1桁以下の入力のため、適切な値を入れる事が出来ない為、NULLを返す
        RETURN NULL;
    END IF;
    IF center = 1 THEN             --１文字目が「：」であるとき
        --開始基準時刻が省略されていると判断し、補完する
        houre_time := root_time;
    ELSE
        --時間部分を取り出す
        houre_time := substring( ins_text from 0 for center)::int;
    END IF;
    --分の部分を取り出す
    minute_time := substring( ins_text from center+1 for 5)::int;
    --24時間表記で、0〜基準時刻のときは24を足す
    IF houre_time < root_time THEN
        houre_time := houre_time + 24;
    ELSE
        --24時間表記で、24+基準時刻の入力までは許可
        IF houre_time - root_time >= 24 THEN
            --範囲外の入力は、正式な解釈が出来ないため無効
            RETURN NULL;
        END IF;
    END IF;
    --開始時間を基点として時間に変更
    houre_time := houre_time - root_time;
    houre_time := houre_time * 60;           --時間単位を分に変換
    total_time := houre_time + minute_time;  --基点時間を計算する
    RETURN total_time;
End;
' LANGUAGE 'plpgsql';

/*-----------------------------------------------------*/
/**
 * TO_CLOCK()
 * 基準時間からの経過分を引数に受け取り、時刻形式の表現を返します。
 * 経過分の有効範囲は、 0〜1439、-1〜-1439 とします。
 * 有効範囲外の数値が引数に与えられた場合、NULLを返します。
 * この為、集計関数中で使用した場合、有効範囲外の数値の影響で集計
 *結果がNULLになる様に考慮してあります。
 * ※プロシージャ作成時に基準時刻(root_time)を変更しておく必要があります。
 *
 * @language     plpgsql
 * @date         2001/11/14
 * @author       t_suzuki
 * @param        integer  基準時間からの経過時間を分単位で表した数値
 * @return       text     ":"区切りの時刻表現された文字列
 */
CREATE or REPLACE FUNCTION to_clock(int)
RETURNS text AS '
Declare
    ins_minute alias for $1;    --引数の別名
    root_time CONSTANT integer NOT NULL DEFAULT 7;    --基準時刻
    clean_minute    integer;    --範囲チェック完了後の値
    hour_time       text;       --時間単位の表示部分
    minute_time     text;       --分単位の表示部分
    clock_text      text;       --戻り値
Begin
    /**
     * 入力範囲チェック
     *   有効範囲 0〜1439/-1〜-1439 （前後基準時間を考慮）
     *   引数がマイナスの場合、基準時刻からの逆経過時間とする
     */
    IF ins_minute >= 0 AND ins_minute < 1440 + root_time * 60 THEN
        --正の有効値をセット
        clean_minute := ins_minute;
    ELSE
        IF ins_minute < 0 AND ins_minute > -1440 - root_time * 60 THEN
            --負の有効値をセット
            clean_minute := ins_minute + 1440;
        ELSE
            --有効範囲外 NULL値を返す
            RETURN NULL;
        END IF;
    END IF;
    /**
     * 整形処理
     * "24:00"を"0:00"と出力する場合、※1の条件をコメントアウトして
     * ※2を使用する。
     */
    --時刻を計算し、TEXT 型に整形する
    --※1  24時以上をそのまま表示する条件
    IF clean_minute >= 1440 THEN
    --※2  24時以上を繰り下げる条件
--  IF clean_minute >= 1440 - root_time * 60 THEN
        hour_time := to_char(clean_minute / 60 - 24 + root_time, ''00'');
    ELSE
        hour_time := to_char(clean_minute / 60 + root_time, ''00'');
    END IF;
    --分を計算し、TEXT 型に整形する
    minute_time    := to_char(clean_minute % 60 , ''00'');
    --文字列の結合
    hour_time  := ltrim(hour_time);
    minute_time := ltrim(minute_time);
    clock_text  := hour_time || '':'' || minute_time;
    RETURN clock_text;
End;
' LANGUAGE 'plpgsql';

----------------------------------------------------
■使用方法
・7：00（基準時刻）からの経過分を返します。
# select to_interval('9:00');
 to_interval
----------
           120

# select to_clock(120);
 to_clock
--------
 09:00

日付を超えた、「在場時間 = 退勤時間 - 出勤時間」は、
以下のように問い合わせ可能です。
select to_clock(to_interval(out_time) - to_interval(in_time)) from jobday;

#目的指向が強く、汎用性はないものですが…。
 -----------------------------------------
      鈴木 徹 (SUZUKI Toru)
      KENWOOD ENGINEERING CORPORATION
      E-mail:t_suzuki ＠ kenwood-eng.co.jp
 -----------------------------------------



From msyk ＠ mtg.biglobe.ne.jp  Mon May 19 23:07:24 2003
From: msyk ＠ mtg.biglobe.ne.jp (MORIYAMA Masayuki)
Date: Mon, 19 May 2003 23:07:24 +0900
Subject: [pgsql-jp: 29991] 【不具合報告】日本語マップの抜け落ち修正パッチ(7.3.X用)
Message-ID: <20030519131900.8889.MSYK@mtg.biglobe.ne.jp>

はじめまして、森山と申します。

最初から、不具合報告で申し訳ありませんが、下記のページにある、
「日本語マップの抜け落ち修正パッチ(7.3.X用) 」で次のような不具合
と、不具合ほどの問題でなくパッチ自体の問題でもありませんが、
Windows のエンコーディング変換との動作の違いがありましたのでご報
告いたします。

[PostgreSQL Bank]
http://www.sankyo-unyu.co.jp/Pool/PostgreSQL.php

(1) UTF-8 ⇔ EUC_JP (eucJP-open/eucJP-ms) の UDC マッピングの不具合
  ・EUC(UDC) の最終バイトが 0xa1 となるべきものが 0xff となっている。
  ・EUC(UDC) の最終バイトが 0xa1 のコードが間違っている。
  ・EUC(UDC) の最終バイトが 0xa2 のコードが抜け落ちている。
  ・EUC -> UTF-8 で変換できないコードがあった。(配列の要素数の数
    え間違いと思われます)

    TOG 日本ベンダ協議会の次のマッピングをそのまま用いると間違い
    は無いと思われます。(大文字のローマ数字、(株)、No.、TEL に関
    して重複符号化されていますが、13区のNEC特殊文字を使うのが妥
    当ではないかと思われます。現状もそうなっていますし。)

    http://www.opengroup.or.jp/jvc/cde/appendix.html
    ※Microsoft Windows 3.51 式の変換 (eucJP-ms) のマッピングを使う。

(2) UTF-8 → SJIS (MS932) のマッピングに関して
  ・大文字のローマ数字および、(株)、No.、TEL のマッピングが、
    Windows の WideCharToMultiByte() のマッピングと異なり、Java 
    の Cp943C コンバータと同一のマッピングとなっているようです。

    Windows でのマッピングは次のようになっています。(大文字のロー
    マ数字等は、NEC特殊文字の 13区を使う)

    マイクロソフト サポート技術情報 - JP170559
    [PRB] SHIFT - JIS と Unicode 間の変換問題 
    http://support.microsoft.com/default.aspx?scid=kb;ja;JP170559

上記の不具合および Windows のエンコーディング変換との不一致を修
正するパッチを次の場所に置いておきます。

  http://www2d.biglobe.ne.jp/~msyk/software/postgresql-7.3.2.ja.diff.gz
  ※ postgresql-7.3.2 からの直接パッチになります。

  パッチの当て方
    postgresql-7.3.2
      $ tar zxvf postgresql-7.3.2.tar.gz
      $ zcat postgresql-7.3.2.ja.diff.gz | patch -p0

    postgresql-7.3.1 (7.3 の場合も同様)
      $ tar zxvf postgresql-7.3.1.tar.gz
      $ cd postgresql-7.3.1
      $ zcat ../postgresql-7.3.2.ja.diff.gz | patch -p1

  UNICODE/EUC_JP の両データベースに対して、Windows-31J(MS932) で
  ユーザー定義外字領域を含む文字定義のある全コードポイントについ
  て、psql 経由で、UNICODE、SJIS(MS932)、EUC_JP(eucJP-open) のそ
  れぞれで読み書きして、正しく変換される事を確認しました。

# Windows が採用している日本語EUC (コードページ 51932) は、いわ
# ゆる機種依存文字に関して、PosgreSQL が採用している TOG 日本ベ
# ンダ協議会の eucJP-open とは互換性が無いのが難点。

‖ 森山 将之 (MORIYAMA, Masayuki) 
‖ E-Mail: msyk ＠ mtg.biglobe.ne.jp 



From sorako_y ＠ hotmail.com  Tue May 20 10:14:40 2003
From: sorako_y ＠ hotmail.com (sorako yamamoto)
Date: Tue, 20 May 2003 01:14:40 +0000
Subject: [pgsql-jp: 29992] Re: 24:00を超えた場合の時刻表示方法について
Message-ID: <Law15-F25jZjCJngp6j000348ed@hotmail.com>

おはようございます。

>既に石田さんが、大変参考になるSQLを紹介されている上、
>ご本人が解決されているので、邪魔でしかないかも知れませんが。。

鈴木さん、邪魔だなんて…とんでもないです。

>こういった処理を、（6時とか7時とか）基準時間をもとに計算したかったので、
>時刻←→Int時間の変換を、PL/pgSQLで関数化してみました。

大変参考になります。ありがとうございます。

ひとつの処理を行うのにも様々な方法がありますね…
その辺も勉強していかないといけないですね。
言語仕様はもちろんですが。

いつになったら自分のやっていることに自信がつくのやら…

これからもどうぞよろしくお願いします。
どうもありがとうございました！

やまもとそらこ。

_________________________________________________________________
最新のファイナンス情報とライフプランのアドバイス MSN マネー  
http://money.msn.co.jp/  



From cdb01160 ＠ hkg.odn.ne.jp  Tue May 20 11:15:48 2003
From: cdb01160 ＠ hkg.odn.ne.jp (cdb01160)
Date: Tue, 20 May 2003 11:15:48 +0900
Subject: [pgsql-jp: 29993] 7.3.X　の　SQL文
Message-ID: <000001c31e75$bdaaa530$1401a8c0@compevod300>

初めまして　佐藤です。

現在失業中で、SQL　の勉強も兼ねて、
http://www.hi-ho.ne.jp/tsumiki/　さんの　CSE　のような
あるいは、
http://www.hi-ho.ne.jp/a_ogawa/　さんの　PSqlEdit　のような
PostgreSQL　専用の　Windows　用のクライアントソフトを作っています。

言語は、Delphi。
コンポーネントは　http://www.est.hi-ho.ne.jp/takeshi_kanno/　さんの
PQCompo　を使い、
通信には、
http://www.interwiz.koganei.tokyo.jp/software/PostgreSQL/index.html
さんの　libpq.dll を使い、
エディター部分には、http://harimawo.com/　さんの　TRichEditEx　を
使っています。

で、psql　のバックスラッシュコマンドで得られる情報は、-E　オプションを
付けて　psql　が表示してくれる　SQL　文をまねて取っているのですが、

PostgreSQL 7.2.3 が出してくる　SQL　文と、7.3.2 が出してくる
それとは、相当違っているのですが、
7.2.3 の　SQL　文で、7.3.2　から必要な情報が得られます。
「互換性」というか、古い　SQL　文のままで良いのでしょうか?

調べた範囲では、
pg_relcheck テーブルが無くなって、pg_constraint テーブルが使われる
ようになった?　（これは、致命的なので書き換えました。）
pga_XXXXXX　テーブルが無くなった?　（関係ないようなので無視）
「Schema」属性が増えた?　（「分散環境?」に備えたものらしいけど、
私には話がでかすぎて理解できていない。）
等で、古いままで良いような気がするのですが、だめでしょうか?

以上　佐藤賢治




From sugita ＠ sra.co.jp  Tue May 20 11:29:33 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Tue, 20 May 2003 11:29:33 +0900 (JST)
Subject: [pgsql-jp: 29994] Re: 7.3.X　の　SQL 文
In-Reply-To: <000001c31e75$bdaaa530$1401a8c0@compevod300>
References: <000001c31e75$bdaaa530$1401a8c0@compevod300>
Message-ID: <20030520.112933.74735702.sugita@sra.co.jp>

  杉田です。

From: "cdb01160" <cdb01160 ＠ hkg.odn.ne.jp>
Subject: [pgsql-jp: 29993] 7.3.X　の　SQL 文
Date: Tue, 20 May 2003 11:15:48 +0900

;;; で、psql　のバックスラッシュコマンドで得られる情報は、-E　オプションを
;;; 付けて　psql　が表示してくれる　SQL　文をまねて取っているのですが、
;;; 
;;; PostgreSQL 7.2.3 が出してくる　SQL　文と、7.3.2 が出してくる
;;; それとは、相当違っているのですが、
;;; 7.2.3 の　SQL　文で、7.3.2　から必要な情報が得られます。
;;; 「互換性」というか、古い　SQL　文のままで良いのでしょうか?
...
;;; 	  古いままで良いような気がするのですが、だめでしょうか?

  バージョンが変わった時のシステムカタログの互換性はありませんので、システムカ
タログを参照するアプリケーションでは、バージョン毎の相違を考えて SQL を書きま
す。従って、アプリケーションの中では、バージョンを判断して SQL を切替える事に
なります。新しいバージョンの方が得られる情報が多かったりするので、古いバージョ
ンの場合には、うまく逃げなければならない場合もあります。


Kenji Sugita                                      


From cdb01160 ＠ hkg.odn.ne.jp  Tue May 20 13:39:59 2003
From: cdb01160 ＠ hkg.odn.ne.jp (cdb01160)
Date: Tue, 20 May 2003 13:39:59 +0900
Subject: [pgsql-jp: 29995] Re: 7.3.X　の　SQL  文
In-Reply-To: <20030520.112933.74735702.sugita@sra.co.jp>
Message-ID: <000001c31e89$e231e760$1401a8c0@compevod300>

　佐藤です。（引用は長くなるので切ります。）

了解しました。シコシコ書き並べる事にします。
ありがとうございました。

以上　佐藤賢治




From tosiyuki ＠ gol.com  Tue May 20 15:00:04 2003
From: tosiyuki ＠ gol.com (Ishikawa Toshiyuki)
Date: Tue, 20 May 2003 15:00:04 +0900
Subject: [pgsql-jp: 29996] 7.3.2 ドキュメント
Message-ID: <E19I09d-0000mk-00@smtp02.fields.gol.com>

JPUG 書籍・文書関連分科会の石川です。

現在分科会の作業結果として 7.2 ベースのドキュメントを Web
で公開しておりますが、SRA さんが PowerGres 開発にあたって、
これを基に独自でリリース 7.3 で変更・追加された部分を翻訳
してPostgreSQL 7.3.2の日本語ドキュメントを作成，製品に添付
商用配布されてきました。コミュニティの成果をベースにしてい
るという観点からも、成果をコミュニティに還元するため、7.3.2
の日本語ドキュメントを JPUG に寄贈したいとのお申し出でがあり、
有難くお受けいたしました。

成果は sgml のソースで頂きましたので、html と man ページを
生成し、本日以下の URL で公開しました。この日本語マニュアル
が皆様のお役に立つことを願っています。

http://www.postgresql.jp/document/pg732doc/index.html

以上


From cdb01160 ＠ hkg.odn.ne.jp  Tue May 20 15:23:32 2003
From: cdb01160 ＠ hkg.odn.ne.jp (cdb01160)
Date: Tue, 20 May 2003 15:23:32 +0900
Subject: [pgsql-jp: 29997] Re: 7.3.2 ドキュメント
In-Reply-To: <E19I09d-0000mk-00@smtp02.fields.gol.com>
Message-ID: <000001c31e98$595daf00$1401a8c0@compevod300>

佐藤です。（長くなるので引用は切りました。）
すばらしい。早速落とさせてもらいました。
以上　佐藤賢治




From koyama ＠ hoge.org  Tue May 20 17:38:49 2003
From: koyama ＠ hoge.org (KOYAMA Tetsuji)
Date: Tue, 20 May 2003 17:38:49 +0900
Subject: [pgsql-jp: 29998] PostgreSQL Plus (仮称)
Message-ID: <87fznaui5i.wl@poseidon.hoge.org>

  小山です。
  すでにいろんなところで話題になってますが、ここではまだみたいなので。

	富士通，オープンソースDBのPostgreSQLと同社DBのSymfoWareを融合
	http://itpro.nikkeibp.co.jp/free/SI/NEWS/20030520/1/

  PostgreSQL の SQL プロセッサ部と SymfoWare のデータ I/O 処理部分を組
み合わせ、vacuum 不要になるとのことですが、追記型アーキテクチャじゃな
くなるみたいなので、oid はどうなっちゃうのかが気になりますね。

-- 
	小山 哲志＠ビート・クラフト
	koyama ＠ beatcraft.com
	koyama ＠ hoge.org


From t-ishii ＠ sra.co.jp  Tue May 20 17:51:15 2003
From: t-ishii ＠ sra.co.jp (Tatsuo Ishii)
Date: Tue, 20 May 2003 17:51:15 +0900 (JST)
Subject: [pgsql-jp: 29999] Re: PostgreSQL Plus (仮称)
In-Reply-To: <87fznaui5i.wl@poseidon.hoge.org>
References: <87fznaui5i.wl@poseidon.hoge.org>
Message-ID: <20030520.175115.15267775.t-ishii@sra.co.jp>

石井です．

>   小山です。
>   すでにいろんなところで話題になってますが、ここではまだみたいなので。
> 
> 	富士通，オープンソースDBのPostgreSQLと同社DBのSymfoWareを融合
> 	http://itpro.nikkeibp.co.jp/free/SI/NEWS/20030520/1/
> 
>   PostgreSQL の SQL プロセッサ部と SymfoWare のデータ I/O 処理部分を組
> み合わせ、vacuum 不要になるとのことですが、追記型アーキテクチャじゃな
> くなるみたいなので、oid はどうなっちゃうのかが気になりますね。

うーん，追記型とOIDは関係ないと思いますよ．
--
Tatsuo Ishii


From yutaka ＠ hi-net.zaq.ne.jp  Tue May 20 18:01:32 2003
From: yutaka ＠ hi-net.zaq.ne.jp (Yutaka tanida)
Date: Tue, 20 May 2003 18:01:32 +0900
Subject: [pgsql-jp: 30000] Re: PostgreSQL Plus (仮称)
In-Reply-To: <87fznaui5i.wl@poseidon.hoge.org>
References: <87fznaui5i.wl@poseidon.hoge.org>
Message-ID: <20030520175400.1BFD.YUTAKA@hi-net.zaq.ne.jp>

谷田です。

On 20 May 2003 17:39:28 +0900
KOYAMA Tetsuji <koyama ＠ hoge.org> wrote:

>   PostgreSQL の SQL プロセッサ部と SymfoWare のデータ I/O 処理部分を組
> み合わせ、vacuum 不要になるとのことですが、追記型アーキテクチャじゃな
> くなるみたいなので、oid はどうなっちゃうのかが気になりますね。

SymfoWareを見たことがないのでどれほどのものになるかは何とも言えませんねぇ。
実際どうなんでしょう？

個人的には、VACUUM不要というのはわりとどうでも良い話（実運用でもたいてい
の場合はConcurrent VACUUMで十分。）で、PITRが含まれるとか、I/O周りの強化
によるパフォーマンス向上とかがポイントになるな、と思ってます。

あと、石井さんも言ってますがOidは関係ないでしょう。

-- 
Yutaka tanida <yutaka ＠ nonsensecorner.com>
http://www.nonsensecorner.com/



From koyama ＠ hoge.org  Tue May 20 18:28:03 2003
From: koyama ＠ hoge.org (KOYAMA Tetsuji)
Date: Tue, 20 May 2003 18:28:03 +0900
Subject: [pgsql-jp: 30001] Re: PostgreSQL Plus (仮称 )
In-Reply-To: <20030520.175115.15267775.t-ishii@sra.co.jp>
References: <87fznaui5i.wl@poseidon.hoge.org>
	<20030520.175115.15267775.t-ishii@sra.co.jp>
Message-ID: <87el2uufvg.wl@poseidon.hoge.org>

  小山です。

At Tue, 20 May 2003 17:51:15 +0900 (JST),
Tatsuo Ishii wrote:
> うーん，追記型とOIDは関係ないと思いますよ．

  はい、そうですね。なんか勘違いしてました。(苦笑)

-- 
	小山 哲志＠ビート・クラフト
	koyama ＠ beatcraft.com
	koyama ＠ hoge.org


From no ＠ kasas.org  Tue May 20 19:11:51 2003
From: no ＠ kasas.org (KASAHARA Norio)
Date: Tue, 20 May 2003 19:11:51 +0900
Subject: [pgsql-jp: 30002] Re: PostgreSQL Plus (仮称 )
In-Reply-To: <20030520175400.1BFD.YUTAKA@hi-net.zaq.ne.jp>
Message-ID: <79E39A8A-8AAB-11D7-B4AC-0003939D0DE6@kasas.org>

かさはらです。こんにちは。

On 2003.5.20, at 18:01 Japan, Yutaka tanida wrote:

> SymfoWareを見たことがないのでどれほどのものになるかは何とも言えませんねぇ。
> 実際どうなんでしょう？
>
SymfoWareという製品名はあまり聞いたことがないと思いますが、RDBの
エンジンは、汎用機で使われていたRDB IIというものを起源としています。
私は、90年にM760という汎用機でRDB IIを使っていました。
当時はWingzやExcelなどをRDBのフロントエンドとして使うシステムが
はやっていました。RDB IIは、Lotus1-2-3と連携することができました。

10年以上の歴史を持っているものですので、それなりに信頼できるものだと
思いますよ。銀行系など基幹系のシステムでも多く使われているはずですし。

--
カさはらのりお     no ＠ kasas.org



From aguri ＠ ssl.fujitsu.com  Tue May 20 21:34:28 2003
From: aguri ＠ ssl.fujitsu.com (Ken-ichi Nakayama)
Date: Tue, 20 May 2003 21:34:28 +0900
Subject: [pgsql-jp: 30003] Re: PostgreSQL Plus (仮称 )
In-Reply-To: <79E39A8A-8AAB-11D7-B4AC-0003939D0DE6@kasas.org>
References: <20030520175400.1BFD.YUTAKA@hi-net.zaq.ne.jp> <79E39A8A-8AAB-11D7-B4AC-0003939D0DE6@kasas.org>
Message-ID: <20030520212335.9296.AGURI@ssl.fujitsu.com>

なかやまです。

On Tue, 20 May 2003 19:11:51 +0900
KASAHARA Norio <no ＠ kasas.org> wrote:
no> On 2003.5.20, at 18:01 Japan, Yutaka tanida wrote:
no> > SymfoWareを見たことがないのでどれほどのものになるかは何とも言えませんねぇ。
no> > 実際どうなんでしょう？
no> SymfoWareという製品名はあまり聞いたことがないと思いますが、RDBの
no> エンジンは、汎用機で使われていたRDB IIというものを起源としています。
no> 私は、90年にM760という汎用機でRDB IIを使っていました。

その汎用機のRDBIIのオープン系実装(Unix/Windows)が、Symfoware Server
です。バージョンがV20L10までがRDBII名称で、その後
ODBII(Jasmineの前進)やその他関連ミドル製品とブランド統合し、
Symfowareとなりました。汎用機側のRDBIIもSymfoware for GSで
ブランド統合されています。

no> 当時はWingzやExcelなどをRDBのフロントエンドとして使うシステムが
no> はやっていました。RDB IIは、Lotus1-2-3と連携することができました。

当時ODBCではなくてDBEAMが主だったですね。

no> 10年以上の歴史を持っているものですので、それなりに信頼できるものだと
no> 思いますよ。銀行系など基幹系のシステムでも多く使われているはずですし。

Oracleよりもはるか前に格納構造のパーティショニング(DSO/DSI分割)を
実装していたり、大規模基幹系やデータウェアハウスなどで実績をあげています。
ただし、今回の発表は個人的には歓迎です(^^) いいとこ取りの予感(^^;)


-- 
中山 賢一   <E-Mai> aguri ＠ ssl.fujitsu.com <Web> http://www.ssl.fujitsu.com 
株式会社富士通ソーシアルサイエンスラボラトリ ビジネス基盤センター 企画部
TEL: 044-739-1566(内線:3612)  FAX: 044-739-1548



From sugita ＠ sra.co.jp  Tue May 20 22:17:55 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Tue, 20 May 2003 22:17:55 +0900 (JST)
Subject: [pgsql-jp: 30004] Re: PostgreSQL Plus (仮称 )
In-Reply-To: <20030520212335.9296.AGURI@ssl.fujitsu.com>
References: <20030520175400.1BFD.YUTAKA@hi-net.zaq.ne.jp>
	<79E39A8A-8AAB-11D7-B4AC-0003939D0DE6@kasas.org>
	<20030520212335.9296.AGURI@ssl.fujitsu.com>
Message-ID: <20030520.221755.85397075.sugita@sra.co.jp>

  杉田です。

From: Ken-ichi Nakayama <aguri ＠ ssl.fujitsu.com>
Subject: [pgsql-jp: 30003] Re: PostgreSQL Plus (仮称 )
Date: Tue, 20 May 2003 21:34:28 +0900

;;; ただし、今回の発表は個人的には歓迎です(^^) いいとこ取りの予感(^^;)

  速いだけでなく、とても素晴らしいことだと思います。

# 個人的には、大量データでの 2 次元 quad-tupple を目論んでいましたが。


Kenji Sugita                                      




From toshitaka.iso ＠ hp.com  Tue May 20 22:33:39 2003
From: toshitaka.iso ＠ hp.com (Iso, Toshitaka)
Date: Tue, 20 May 2003 22:33:39 +0900
Subject: [pgsql-jp: 30005] Re: SET STATISTICS の統計情報の目標値決定指標
Message-ID: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E02340678@tkoexc02.asiapacific.cpqcorp.net>

杉田さん。

返答ありがとうございます。

区分値の割合を調べてみたところ、以下のようになりました。

総件数と、Kubunごとの割合と、Index Scanをしてくれるのは、
割合が1%未満のものだけでした。

割合が少なくても持ってくる件数が多いと、Index Scanではなく
Seq Scanになってしまうのでしょうか。

このIndex　Scanをしてくれる可能性を高める方法は、enable_Seq_scan
のパラメータのみでしか制御は不可能でしょうか？

DKBN	COUNT	％
000100	266250	1.22%
000200	234255	1.08%
010100	237063	1.09%
010200	234255	1.08%
010300	467809	2.15%
010400	466234	2.14%
011100	261	0.00%
011200	170855	0.78%
011300	84943	0.39%
030100	259089	1.19%
030101	286203	1.31%
030102	513681	2.36%
030200	256338	1.18%
030201	245096	1.13%
030300	252652	1.16%
030301	250757	1.15%
030302	250752	1.15%
030303	6267	0.03%
030304	1	0.00%
030400	507217	2.33%
030500	785	0.00%
030600	206463	0.95%
030700	505621	2.32%
031100	1371	0.01%
031101	1489	0.01%
031102	132331	0.61%
031103	133164	0.61%
031104	138753	0.64%
031105	133936	0.62%
031200	251602	1.16%
031300	31492	0.14%
031301	31492	0.14%
040100	2855069	13.11%
040200	2777782	12.76%
040300	837597	3.85%
040400	1020048	4.68%
050100	268891	1.23%
050200	256902	1.18%
050300	257113	1.18%
050400	251799	1.16%
050500	657	0.00%
050600	2241	0.01%
050700	1619	0.01%
050800	67206	0.31%
050900	100561	0.46%
051000	134219	0.62%
051100	100409	0.46%
051200	103932	0.48%
051400	251845	1.16%
051500	104385	0.48%
051600	255632	1.17%
051700	243262	1.12%
051800	1263	0.01%
051900	33660	0.15%
052000	251851	1.16%
052100	251841	1.16%
052200	257179	1.18%
052300	256023	1.18%
060100	264995	1.22%
060101	253916	1.17%
060102	248997	1.14%
060103	248991	1.14%
060104	67587	0.31%
060105	134685	0.62%
060106	94	0.00%
060200	260155	1.19%
060201	248983	1.14%
060202	248975	1.14%
060203	248969	1.14%
060204	67079	0.31%
060205	99976	0.46%
060206	132959	0.61%
060207	99880	0.46%
060208	102178	0.47%
060300	259659	1.19%
060301	248969	1.14%
060302	248969	1.14%
060303	248964	1.14%
060304	67577	0.31%
060305	99160	0.46%
060306	131355	0.60%
060307	99097	0.46%
060308	101143	0.46%
070100	17205	0.08%
070101	6084	0.03%
070102	6078	0.03%
070103	4202	0.02%
070104	671	0.00%
070105	49	0.00%
070109	5232	0.02%
070110	34	0.00%
070200	231	0.00%
070201	73	0.00%
070202	73	0.00%
070203	1	0.00%
070204	35	0.00%
計        21774743

【Index ScanをするときのExplain Analyze結果】
SMSv04=# explain analyze select * from tbl_hogemgr where kubun='031104';
NOTICE:  QUERY PLAN:

Index Scan using idx_kubun on tbl_hogemgr  
(cost=0.00..558891.96 rows=140084 width=92) (actual time=51.91..665892.86 rows=138753 loops=1)
Total runtime: 666050.53 msec
EXPLAIN

【Seq ScanをするときのExplain Analyze結果】
SMSv04=# explain analyze select * from tbl_hogemgr where kubun='060300';
NOTICE:  QUERY PLAN:

Seq Scan on tbl_hogemgr  
(cost=0.00..629401.30 rows=251135 width=92) (actual time=0.13..115345.13 rows=259659 loops=1)
Total runtime: 115556.81 msec
EXPLAIN

以上です。


From ken ＠ tydfam.jp  Tue May 20 22:45:52 2003
From: ken ＠ tydfam.jp (Yamada Ken Takeshi)
Date: Tue, 20 May 2003 22:45:52 +0900 (JST)
Subject: [pgsql-jp: 30006] Re: PostgreSQL Plus (仮称)
References: <87fznaui5i.wl@poseidon.hoge.org>
Message-ID: <20030520.224552.730552751.ken@tydfam.jp>

  公開される jdbc に期待！！




From sugita ＠ sra.co.jp  Tue May 20 22:59:39 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Tue, 20 May 2003 22:59:39 +0900 (JST)
Subject: [pgsql-jp: 30007] Re: SET STATISTICS の統計情報の目標値決定指標
In-Reply-To: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E02340678@tkoexc02.asiapacific.cpqcorp.net>
References: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E02340678@tkoexc02.asiapacific.cpqcorp.net>
Message-ID: <20030520.225939.59668519.sugita@sra.co.jp>

  磯さん、今晩は。

From: "Iso, Toshitaka" <toshitaka.iso ＠ hp.com>
Subject: [pgsql-jp: 30005] Re: SET STATISTICS の統計情報の目標値決定指標
Date: Tue, 20 May 2003 22:33:39 +0900

;;; 区分値の割合を調べてみたところ、以下のようになりました。
;;; 
;;; 総件数と、Kubunごとの割合と、Index Scanをしてくれるのは、
;;; 割合が1%未満のものだけでした。

  興味深い調査結果をありがとうございます。こういうデータがあるとのめり込みたく
なります。

;;; 割合が少なくても持ってくる件数が多いと、Index Scanではなく
;;; Seq Scanになってしまうのでしょうか。

  データの分布傾向は影響します。極端な場合、一様乱数に近いと、PostgreSQL のオ
プティマイザは、インデックススキャンとシーケンシャルスキャンの予測コスト比較で
actual とかなり違う予測をしてしまいます。

  他には、7.3 迄では、IN 副問い合わせの予測コストも、実際と 1 桁以上合わなくな
ることが殆どで、効率を考えると、副問い合わせの使用にかなりの制約があるのは、と
てもアプリケーション側に辛いと思えます。

;;; このIndex　Scanをしてくれる可能性を高める方法は、enable_Seq_scan
;;; のパラメータのみでしか制御は不可能でしょうか？

  PostgreSQL では、これは最後の手段です。あるいは、JOIN によるクエリーの書き換
えです。理想的な SQL 的にしたくはありませんが、実際的には、PostgreSQL は、
Oracle のようにどのインデックスを使うべきか迄の制御をユーザが制御できないのが
もどかしいです。

  完全な予測をできないのであれば、Oracle のように、使用者に実行計画の制御の手
段を与えるべきです。


Kenji Sugita                                      



From t-ishii ＠ sra.co.jp  Tue May 20 23:36:02 2003
From: t-ishii ＠ sra.co.jp (Tatsuo Ishii)
Date: Tue, 20 May 2003 23:36:02 +0900 (JST)
Subject: [pgsql-jp: 30008] Re: SET STATISTICS の統計情報の目標値決定指標
In-Reply-To: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E02340678@tkoexc02.asiapacific.cpqcorp.net>
References: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E02340678@tkoexc02.asiapacific.cpqcorp.net>
Message-ID: <20030520.233602.41632874.t-ishii@sra.co.jp>

石井です．

> 割合が少なくても持ってくる件数が多いと、Index Scanではなく
> Seq Scanになってしまうのでしょうか。

それは当然そうでしょう．インデックススキャンでは，

(1) インデックスから該当エントリを検索．MVCCの関係で複数タプルが見つか
    ることがあるので，それぞれのタプルについて以下を処理する．

(2) テーブルのTIDを知る

(3) そのTIDを使ってテーブルの該当レコードをアクセスする

(4) そのレコードが，このトランザクションから見てデッドタプルでないこと
    を検査

(5) OKなら検索完了，そうでなければ(2)に戻る

というように余計なディスクアクセスが入るので，検索件数が多ければ多いほ
ど順スキャンよりも高コストになる傾向があります．

> このIndex　Scanをしてくれる可能性を高める方法は、enable_Seq_scan
> のパラメータのみでしか制御は不可能でしょうか？

もしも強制的にインデックスを使わせてみて，そちらの方が順スキャンよりも
実際には高速である場合には，カーネルのバッファキャッシュなどの影響で，
ディスクアクセスが多いにも関わらず高速に処理できている可能性も考えられ
ます．その場合はとりあえず，effective_cache_size を10-100倍くらいに増
やしてみてはどうでしょう．

また，

SELECT * FROM .... LIMIT 100000;

のように，ダミーのLIMIT句を付けると効果がある場合もあるようです．

ところで，素朴な疑問ですが，検索結果が20万件もあると，フロントエンドに
転送するだけでも結構な時間がかかってしまいますし，受け取る方も膨大なメ
モリを消費します．そういうDBアプリケーションの設計は果たして妥当なので
しょうか？
--
Tatsuo Ishii


From hayakawa ＠ sam.hi-ho.ne.jp  Wed May 21 07:39:11 2003
From: hayakawa ＠ sam.hi-ho.ne.jp (HAYAKAWA Hiroshi)
Date: Wed, 21 May 2003 07:39:11 +0900
Subject: [pgsql-jp: 30009] Re: oid の同一性と生成ロジックについて
In-Reply-To: <20030519133711.DB3D.YUTAKA@hi-net.zaq.ne.jp>
Message-ID: <BAF0DD9F.22FBC%hayakawa@sam.hi-ho.ne.jp>

おはようございます。早川＠名古屋です。

返信が遅れてすみません。

on 03.5.19 1:47 PM, Yutaka tanida at yutaka ＠ hi-net.zaq.ne.jp wrote:

>> ちなみに、いまは、ウェブアプリケーションにおいて、
>> 新規データの登録時に、INSERTの後にoidを取得し、
>> そのoidを用いてそのデータのシリアルなIDを取得する、
>> というロジックを多用しています。
> 
> そもそも、そのロジックがあまりよろしくないと思います。この場合のID取得に
> はcurrval()関数を使うとか、serial型を使わずに自前でsequence管理するのが
> 筋でしょう。

on 03.5.19 5:52 PM, mitani at mitani ＠ sraw.co.jp wrote:

>> だから、それがクエリベースのレプリケーションの欠点であり、最初の記事はそ
>> れを指摘しているのです。
> これもその通りでして，クエリーベースのレプリケーションではnow()のような
> ものをINSERTされても，その値を全部のDBで整合性を保障できないのです．

そうですね。記事を読ませていただいて「あぁ」と思ったのですが、
当初はUsogresを利用するつもりはなくて（というか、存在を知りませんでした）
いままで気がつきませんでした。
テーブル定義中で DEFAULT 'now' などとしているのもダメですね。

確認できてすっきりしました。ありがとうございました。


目的としては負荷分散ではなくフェールオーバのためを意図していましたので、
まずはRAID1にてサーバーを運用することと、ベタではありますが、
HDD以外のハードウェア障害に対しては代わりのサーバーを用意しておいて
障害時には切り替える（HDDを手で入れ替えorデータをコピー）という方法で、
また負荷分散はDBサーバー以外の機能を別のマシンに移すといった方法にて
間に合いそうです。

レプリケーションを利用しようと考える場合には
設計時からちゃんと考えておく必要がありますね。

 * * *

ところで、クエリベースではないレプリケーションの実装というのは
やはり相当複雑で難しいことなのですよね？
その関連でRAID1の処理ロジックを知りたいなと思ったのですが、
適当なページをみつけることができませんでした。
LinuxのソフトウェアRAIDのドキュメントかソースを追っかけると
少し理解が深められるかもしれないので、
機会をみてちょっとみてみたいと思っています。


-----
With your dreaming, with your smile.
Hayakawa, Hiroshi <hayakawa ＠ sam.hi-ho.ne.jp>
Nagoya,Aichi,JAPAN ☆彡



From nakama ＠ ki.rim.or.jp  Wed May 21 09:34:36 2003
From: nakama ＠ ki.rim.or.jp (Ei-ji Nakama)
Date: Wed, 21 May 2003 09:34:36 +0900 (JST)
Subject: [pgsql-jp: 30010] PostgreSQL on R
Message-ID: <20030521.093436.607955858.nakama@ki.rim.or.jp>

なかまです。

http://phi.ypu.jp/swtips/R.html によれば、Rはあんまり流行って
無いようなので、PostgreSQLとRの繋ぎの部分を書いてみました。

http://www.nakama.ne.jp/memo/cran-R/

参考になれば幸いです。
--
e-mail : Ei-ji Nakama <nakama ＠ ki.rim.or.jp>


From t-ishii ＠ sra.co.jp  Wed May 21 10:25:50 2003
From: t-ishii ＠ sra.co.jp (Tatsuo Ishii)
Date: Wed, 21 May 2003 10:25:50 +0900 (JST)
Subject: [pgsql-jp: 30011] Re: SET STATISTICS の統計情報の目標値決定指標
In-Reply-To: <20030520.225939.59668519.sugita@sra.co.jp>
References: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E02340678@tkoexc02.asiapacific.cpqcorp.net>
	<20030520.225939.59668519.sugita@sra.co.jp>
Message-ID: <20030521.102550.41631220.t-ishii@sra.co.jp>

石井です．

>   他には、7.3 迄では、IN 副問い合わせの予測コストも、実際と 1 桁以上合わなくな
> ることが殆どで、効率を考えると、副問い合わせの使用にかなりの制約があるのは、と
> てもアプリケーション側に辛いと思えます。

というか，副問い合わせの結果をWHERE句で利用する場合，WHERE句条件の適合
率の予測が常に50%固定になってしまうのが問題なのですよ（これは，関数の
結果をWHERE句で評価する場合も同じことが言えます）．副問い合わせの結果
をブラックボックスとして扱う以上は，しょうがないんじゃないかな．

ご存じのように，7.4では，この手の副問い合わせは内部で展開されて副問い
合わせじゃなくなるので，このあたりはかなり改善されています．

>   完全な予測をできないのであれば、Oracle のように、使用者に実行計画の制御の手
> 段を与えるべきです。

さあ，それはどうなんでしょうね．ユーザがオプティマイザよりも賢ければ良
いのですが，賢くないユーザは（たとえば）何が何でもインデックスを使おう
としてはまるでしょう．

逆にユーザがオプティマイザよりも賢いとすると，ヒント句など使うまでもな
く，迷えるオプティマイザが正しい問い合わせ計画を導き出すように手助けす
ることができます．

ヒント句で問題なのは，実行計画が固定化されやすいことだと思います．検索
条件が変化したり，データ量が変化した場合でも同じ実行計画を使い続けると
気が付かない間にパフォーマンスが劣化します．更に言えば，PostgreSQLのバー
ジョンが上がってよりよい問い合わせ実行方法が導入されても，SQLを書き換
えないとそれが利用できないかもしれません．

さらに，利用者が実行計画をどのように指示するかも問題です．SQLにコメン
トを追加する程度では，複雑な実行計画を完全に指示することはできないでしょ
う．現実的には，「どのインデックスを使え」位しか指示できないのではない
でしょうか．でもそれだと set enable_* to off とたいして変りません．
その程度で良ければ簡単に実装できると思いますが．
--
Tatsuo Ishii


From mitani ＠ sraw.co.jp  Wed May 21 10:34:46 2003
From: mitani ＠ sraw.co.jp (mitani)
Date: Wed, 21 May 2003 10:34:46 +0900
Subject: [pgsql-jp: 30012] Re: oid の同一性と生成ロジックについて
In-Reply-To: <BAF0DD9F.22FBC%hayakawa@sam.hi-ho.ne.jp>
References: <20030519133711.DB3D.YUTAKA@hi-net.zaq.ne.jp> <BAF0DD9F.22FBC%hayakawa@sam.hi-ho.ne.jp>
Message-ID: <20030521102534.A520.MITANI@sraw.co.jp>

三谷＠広島です．

> ところで、クエリベースではないレプリケーションの実装というのは
> やはり相当複雑で難しいことなのですよね？
レプリケーションの方法にはQueryベース以外にもLogベースとか，Rowベースと
か色々あります．どの方法でもハードディスクに書かれるデータのレプリケーショ
ンはそれほど難しくないのですが，メモリに持っているデータやロック，トラン
ザクション状態をどうやって同期をとるかが難しいです（非同期レプリケーショ
ンだとこの辺りは割り切って作ることができますが）．

> LinuxのソフトウェアRAIDのドキュメントかソースを追っかけると
> 少し理解が深められるかもしれないので、
> 機会をみてちょっとみてみたいと思っています。
何か面白いことが分かったら教えてください．

=============================
三谷　篤<mitani ＠ sraw.co.jp>
=============================





From hyoshiok ＠ miraclelinux.com  Wed May 21 10:22:55 2003
From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka)
Date: Wed, 21 May 2003 10:22:55 +0900
Subject: [pgsql-jp: 30013] Re: PostgreSQL Plus (仮称 )
In-Reply-To: <20030520212335.9296.AGURI@ssl.fujitsu.com>
References: <20030520175400.1BFD.YUTAKA@hi-net.zaq.ne.jp>
	<79E39A8A-8AAB-11D7-B4AC-0003939D0DE6@kasas.org>
	<20030520212335.9296.AGURI@ssl.fujitsu.com>
Message-ID: <20030521102255H.hyoshiok@miraclelinux.com>

よしおかです。

> なかやまです。

こんにちは〜

今回の発表のポイントがよくわからなかったんですが、
教えてください。

簡単に言ってしまうと、PostgreSQL用に書いたアプリケーションを
一切変更なく、SymfoWareエンジンで動かすことができるつーこと
でしょうか？

> no> 10年以上の歴史を持っているものですので、それなりに信頼できるものだと
> no> 思いますよ。銀行系など基幹系のシステムでも多く使われているはずですし。
> 
> Oracleよりもはるか前に格納構造のパーティショニング(DSO/DSI分割)を
> 実装していたり、大規模基幹系やデータウェアハウスなどで実績をあげています。
> ただし、今回の発表は個人的には歓迎です(^^) いいとこ取りの予感(^^;)

PostgreSQLの下半分(データストレージレイヤ)がしょぼいので
商用RDBMSの下半分におきかえた。値段も安くして、羊の皮をかぶった
狼である〜

PostgreSQLの立場はどうなんでしょう？

よ
--
Hiro Yoshioka/CTO, Miracle Linux
mailto:hyoshiok ＠ miraclelinux.com
http://www.miraclelinux.com
今月の目標：バグフィックス


From sakata.tetsuo ＠ lab.ntt.co.jp  Wed May 21 10:57:05 2003
From: sakata.tetsuo ＠ lab.ntt.co.jp (Tetsuo SAKATA)
Date: Wed, 21 May 2003 10:57:05 +0900
Subject: [pgsql-jp: 30014] Re: PostgreSQL on R
References: <20030521.093436.607955858.nakama@ki.rim.or.jp>
Message-ID: <3ECADCF1.E7153412@lab.ntt.co.jp>

坂田@横須賀(Rユーザ歴3年...)です．

情報ありがとうございます．＞なかま さま

RとPostgreSQLを繋いでみようと考えていたので，
個人的には嬉しい情報です．
(あと，日本語表示の実行例があるのも!)

こういう道具があると，DBのデータを統計ソフトで処理が簡単に
できるので，データマイニングとか視覚化とかには嬉しいですね．

あと，お節介ですが；
http://www.nakama.ne.jp/memo/cran-R/Rdbi.PgSQL/index.html
↑のページに，"R Data Import/Export"を参照しておくと，
何をやっているのかが分かりやすくなって，親切ではないかと思いました．

#Rが流行っていない，というのは事実誤認かなぁ．

#確かに，SPSSのような商用の統計パッケージほど有名では
#ないのでしょうが，基本的な処理は一通りかけるし，
#S言語のクローンなので教科書やネット上のスクリプトも
#豊富に入手できるという利点もありますしから，
#フリーの統計ソフトでは，もっとも普及しているものだと思っています．

Ei-ji Nakama wrote:
> http://phi.ypu.jp/swtips/R.html によれば、Rはあんまり流行って
> 無いようなので、PostgreSQLとRの繋ぎの部分を書いてみました。
> 
> http://www.nakama.ne.jp/memo/cran-R/
> 
> 参考になれば幸いです。
> --
> e-mail : Ei-ji Nakama <nakama ＠ ki.rim.or.jp>

-- 
	NTT サイバースペース研究所	sakata.tetsuo ＠ lab.ntt.co.jp
	坂田　哲夫			Tel: 046-859-2765
					Fax: 046-859-2768


From pg ＠ matznaga.net  Wed May 21 11:10:54 2003
From: pg ＠ matznaga.net (松永 均)
Date: Wed, 21 May 2003 11:10:54 +0900 (JST)
Subject: [pgsql-jp: 30015] Re: PostgreSQL on R
In-Reply-To: <3ECADCF1.E7153412@lab.ntt.co.jp>
References: <20030521.093436.607955858.nakama@ki.rim.or.jp>
	<3ECADCF1.E7153412@lab.ntt.co.jp>
Message-ID: <20030521.111054.42801188.pg@matznaga.net>

松永です。

> 坂田@横須賀(Rユーザ歴3年...)です．

> #Rが流行っていない，というのは事実誤認かなぁ．

どうなんでしょ。

> #確かに，SPSSのような商用の統計パッケージほど有名では
> #ないのでしょうが，基本的な処理は一通りかけるし，

debian には R(S like) も pspp(spss compatible) もパッケージがありますね。

ii  r-base         1.6.0.rel-1  GNU R statistical computing language and envir
ii  r-base-core    1.6.0.rel-1  GNU R core of statistical computing language a
ii  r-base-html    1.6.0.rel-1  GNU R html docs for statistical computing syst
ii  r-base-latex   1.6.0.rel-1  GNU R LaTeX docs for statistical computing sys
ii  r-doc-html     1.6.0.rel-1  GNU R html manuals for statistical computing s
ii  r-doc-info     1.6.0.rel-1  GNU R info manuals statistical computing syste
ii  r-doc-pdf      1.6.0.rel-1  GNU R pdf manuals for statistical computing sy
ii  r-recommended  1.5.1-0woody1 GNU R collection of recommended packages      

ii  pspp           0.3.0-7        Statistical analysis tool

実際のところ、どっちが普及してるんでしょ。


From sugita ＠ sra.co.jp  Wed May 21 11:22:36 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Wed, 21 May 2003 11:22:36 +0900 (JST)
Subject: [pgsql-jp: 30016] Re: SET STATISTICS の統計情報の目標値決定指標
In-Reply-To: <20030521.102550.41631220.t-ishii@sra.co.jp>
References: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E02340678@tkoexc02.asiapacific.cpqcorp.net>
	<20030520.225939.59668519.sugita@sra.co.jp>
	<20030521.102550.41631220.t-ishii@sra.co.jp>
Message-ID: <20030521.112236.41649964.sugita@sra.co.jp>

From: Tatsuo Ishii <t-ishii ＠ sra.co.jp>
Subject: [pgsql-jp: 30011] Re: SET STATISTICS の統計情報の目標値決定指標
Date: Wed, 21 May 2003 10:25:50 +0900 (JST)

;;; ご存じのように，7.4では，この手の副問い合わせは内部で展開されて副問い
;;; 合わせじゃなくなるので，このあたりはかなり改善されています．

  副問い合わせで効率がネックにならないのは、7.4 からですね。7.3 迄は、副問い合
わせを使うには、効率面では注意が必要です。 


Kenji Sugita                                      




From nakama ＠ ki.rim.or.jp  Wed May 21 12:21:46 2003
From: nakama ＠ ki.rim.or.jp (Ei-ji Nakama)
Date: Wed, 21 May 2003 12:21:46 +0900 (JST)
Subject: [pgsql-jp: 30017] Re: PostgreSQL on R
In-Reply-To: <3ECADCF1.E7153412@lab.ntt.co.jp>
References: <20030521.093436.607955858.nakama@ki.rim.or.jp>
	<3ECADCF1.E7153412@lab.ntt.co.jp>
Message-ID: <20030521.122146.640900813.nakama@ki.rim.or.jp>

なかまっす。

Wed, 21 May 2003 10:57:05 +0900
Tetsuo SAKATA <sakata.tetsuo ＠ lab.ntt.co.jp> wrote.
> 坂田@横須賀(Rユーザ歴3年...)です．

どうもです。

> RとPostgreSQLを繋いでみようと考えていたので，
> 個人的には嬉しい情報です．
> (あと，日本語表示の実行例があるのも!)

とりあえず、Xlibまわりだけでも、i18nに出来ないか眺めている
所ですが、挫折寸前です。(笑)
# Xtなら一寸わかるけど、Xlibはつらい。。。

> こういう道具があると，DBのデータを統計ソフトで処理が簡単に
> できるので，データマイニングとか視覚化とかには嬉しいですね．

ぐぐると出てくる難しい統計の話は私にはわかりませんが、個人的
にはDBをグラフ化するケースは多いのでRもそのひとつに加えたいと
思っています。
# 一時期、Sはつかってたんですが、まあどこでもちょこっと使いたい
# 場合には非常に高価ですから。

> あと，お節介ですが；
> http://www.nakama.ne.jp/memo/cran-R/Rdbi.PgSQL/index.html
> ↑のページに，"R Data Import/Export"を参照しておくと，
> 何をやっているのかが分かりやすくなって，親切ではないかと思いました．

加えておきました。
# 日本語ドキュメントあったんですね。(^^;

> #Rが流行っていない，というのは事実誤認かなぁ．
> 
> #確かに，SPSSのような商用の統計パッケージほど有名では
> #ないのでしょうが，基本的な処理は一通りかけるし，
> #S言語のクローンなので教科書やネット上のスクリプトも
> #豊富に入手できるという利点もありますしから，
> #フリーの統計ソフトでは，もっとも普及しているものだと思っています．

うーん、どうなんでしょうね。?

--
e-mail : Ei-ji Nakama <nakama ＠ ki.rim.or.jp>


From zenobia ＠ palmyra.ne.jp  Wed May 21 12:25:14 2003
From: zenobia ＠ palmyra.ne.jp (末光美恵)
Date: Wed, 21 May 2003 12:25:14 +0900
Subject: [pgsql-jp: 30018] コネクションプールが最大数を越えます
Message-ID: <3ECAF19A.8020008@palmyra.ne.jp>

末光と申します。

datasource を使って postgreSQL に接続するjava servlet アプリケーションプ
ログラムを作成しています。

WEBアプリケーションが接続のcloseに失敗した場合、利用不可能な接続がプール
の最大値に達するとデータベースに接続できなくなってしまいます。
この現象を解決できなくて困っています。


postgres: postgres dbname 127.0,0,1 idle　(dbname はデータベース名)

というプロセスが３０以上になった時に必ずデータベースにアクセスできなく
なってアプリケーションが異常終了します。

解決方法として試みたのは
１．アプリケーションプログラムで必ずコネクションを close する
　　当たり前ですが、これが信頼できないので、溜まったコネクションプールを
　　破棄するのが今回の命題です。
２．removeAbandoned を true にする
　　利用不可能になった接続を再利用するとありますが、これを設定しても解決
　　していません。server.xml の設定は以下のとおりです

             <parameter>
               <name>maxActive</name>
               <value>60</value>
             </parameter>
             <parameter>
               <name>maxIdle</name>
               <value>10</value>
             </parameter>
             <parameter>
               <name>maxWait</name>
               <value>100000</value>
             </parameter>
             <parameter>
               <name>removeAbandoned</name>
               <value>true</value>
             </parameter>
             <parameter>
               <name>removeAbandonedTimeout</name>
               <value>300</value>
             </parameter>
             <parameter>
               <name>logAbandoned</name>
               <value>true</value>
             </parameter>

３．maxActive や maxIdle の値をいろいろ変えて試してみましたが、効果なし
　　不思議なのは maxActive の値を 100 とか 300 とかにしても
　　postgres: postgres dbname 127.0,0,1 idle　(dbname はデータベース名)
　　のプロセスが３０以上になるとアプリケーションが落ちます。
４．tomcat を再起動する
　　現状は症状がある度に再起動で解決しています

無駄なコネクションプールを破棄する方法を教えて下さい。
環境は
	RedHat8.0
	J2SDK-1.4.1.01
	Tomcat-4.1.18
	postgreSQL-7.3.2
	Ant-1.5.1
です。









From yutaka ＠ hi-net.zaq.ne.jp  Wed May 21 12:38:55 2003
From: yutaka ＠ hi-net.zaq.ne.jp (Yutaka tanida)
Date: Wed, 21 May 2003 12:38:55 +0900
Subject: [pgsql-jp: 30019] Re: コネクションプールが最大数を越えます
In-Reply-To: <3ECAF19A.8020008@palmyra.ne.jp>
References: <3ECAF19A.8020008@palmyra.ne.jp>
Message-ID: <20030521123623.3C3F.YUTAKA@hi-net.zaq.ne.jp>

谷田です。

On 21 May 2003 12:24:59 +0900
末光美恵 <zenobia ＠ palmyra.ne.jp> wrote:

> 解決方法として試みたのは
> １．アプリケーションプログラムで必ずコネクションを close する

残念なことに、これを徹底する以外に根本的な解決法はありません。

> 　　していません。server.xml の設定は以下のとおりです
(snip)
>              <parameter>
>                <name>maxActive</name>
>                <value>60</value>
>              </parameter>
(snip)
> 　　不思議なのは maxActive の値を 100 とか 300 とかにしても
> 　　postgres: postgres dbname 127.0,0,1 idle　(dbname はデータベース名)
> 　　のプロセスが３０以上になるとアプリケーションが落ちます。

PostgreSQLの最大接続数は変更されましたか？

-- 
Yutaka tanida <yutaka ＠ nonsensecorner.com>
http://www.nonsensecorner.com/



From kmatsuda ＠ lisonal.com  Wed May 21 13:19:00 2003
From: kmatsuda ＠ lisonal.com (松田勝己)
Date: Wed, 21 May 2003 13:19:00 +0900
Subject: [pgsql-jp: 30020] Re: コネクションプールが最大数を越えます
In-Reply-To: <20030521123623.3C3F.YUTAKA@hi-net.zaq.ne.jp>
References: <20030521123623.3C3F.YUTAKA@hi-net.zaq.ne.jp>
Message-ID: <200305210419.AA00719@kmatsuda.lisonal.com>

松田＠リソナルです

Yutaka tanida さんは書きました:
>On 21 May 2003 12:24:59 +0900
>末光美恵 <zenobia ＠ palmyra.ne.jp> wrote:
>
>> 解決方法として試みたのは
>> １．アプリケーションプログラムで必ずコネクションを close する
>
>残念なことに、これを徹底する以外に根本的な解決法はありません。
>
>> 　　していません。server.xml の設定は以下のとおりです
>(snip)
>>              <parameter>
>>                <name>maxActive</name>
>>                <value>60</value>
>>              </parameter>
>(snip)
>> 　　不思議なのは maxActive の値を 100 とか 300 とかにしても
>> 　　postgres: postgres dbname 127.0,0,1 idle　(dbname はデータベース名)
>> 　　のプロセスが３０以上になるとアプリケーションが落ちます。
>
>PostgreSQLの最大接続数は変更されましたか？

Googleとかで「PostgreSQL 最大接続数」というキーワード
で検索すればすぐわかると思いますが
<PostgreSQLインストールディレクトリ>/data/postgresql.conf
内の max_connections という項目を適当な数値に変えて下さい。

また、接続数が増えるとPostgreSQLが使うメモリ量も増えるので
shared_buffers 辺りも増やすことをお忘れなく。

------------------------------
有限会社リソナル 松田 勝己
E-Mail:kmatsuda ＠ lisonal.com URL:http://www.lisonal.com/
TEL   :03-3643-4991 FAX:03-3643-4993
得盛サーバーハウジング
http://www.lisonal.com/index.php?%5B%5B%C6%C0%C0%B9%5D%5D


From aguri ＠ ssl.fujitsu.com  Wed May 21 20:55:43 2003
From: aguri ＠ ssl.fujitsu.com (Ken-ichi Nakayama)
Date: Wed, 21 May 2003 20:55:43 +0900
Subject: [pgsql-jp: 30021] Re: PostgreSQL Plus (仮称 )
In-Reply-To: <20030521102255H.hyoshiok@miraclelinux.com>
References: <20030520212335.9296.AGURI@ssl.fujitsu.com> <20030521102255H.hyoshiok@miraclelinux.com>
Message-ID: <20030521194517.780F.AGURI@ssl.fujitsu.com>

なかやまです。

On Wed, 21 May 2003 10:22:55 +0900
Hiro Yoshioka <hyoshiok ＠ miraclelinux.com> wrote:
hyoshiok> こんにちは〜

どうもです〜

hyoshiok> 今回の発表のポイントがよくわからなかったんですが、
hyoshiok> 教えてください。
hyoshiok> 簡単に言ってしまうと、PostgreSQL用に書いたアプリケーションを
hyoshiok> 一切変更なく、SymfoWareエンジンで動かすことができるつーこと
hyoshiok> でしょうか？

そこまでSymfowareに対してインサイダーではないので
そこまではわからなないです申し訳ない(^^;)
本日からのLinuxWorldでの富士通のミニセミナーでやるかもしれませんねぇ。
いや、ほんとに知らないんですよ。私も寝耳に水で(^^;)
ただ、Interstage PlusでEclipseにCommit しますので、
それと同じラインからすると納得(^^)

hyoshiok> PostgreSQLの下半分(データストレージレイヤ)がしょぼいので
hyoshiok> 商用RDBMSの下半分におきかえた。値段も安くして、羊の皮をかぶった
hyoshiok> 狼である〜

イメージ的にはジェットエンジン付FIAT500みたいだったらいいな、と(^^;)

hyoshiok> PostgreSQLの立場はどうなんでしょう？

7.4 でアーカイブログとレプリケーションサポートですから、
そちらはそちらで順調なのではないかと(^^;)

-- 
中山 賢一   <E-Mai> aguri ＠ ssl.fujitsu.com <Web> http://www.ssl.fujitsu.com 
株式会社富士通ソーシアルサイエンスラボラトリ ビジネス基盤センター 企画部
TEL: 044-739-1566(内線:3612)  FAX: 044-739-1548



From yshim ＠ storgate.co.jp  Wed May 21 21:01:56 2003
From: yshim ＠ storgate.co.jp (Yoichi Shimada)
Date: Wed, 21 May 2003 21:01:56 +0900
Subject: [pgsql-jp: 30022] Re: oid の同一性と生成ロジックについて
In-Reply-To: <BAF0DD9F.22FBC%hayakawa@sam.hi-ho.ne.jp>
References: <BAF0DD9F.22FBC%hayakawa@sam.hi-ho.ne.jp>
Message-ID: <20030521120157.7182@mail.h3.dion.ne.jp>

島田@Storgate と申します。


2003.05.21, 7:39, HAYAKAWA Hiroshi san Wrote;
>on 03.5.19 5:52 PM, mitani at mitani ＠ sraw.co.jp wrote:
>
>>> だから、それがクエリベースのレプリケーションの欠点であり、最初の記事はそ
>>> れを指摘しているのです。
>> これもその通りでして，クエリーベースのレプリケーションではnow()のような
>> ものをINSERTされても，その値を全部のDBで整合性を保障できないのです．
>
>そうですね。記事を読ませていただいて「あぁ」と思ったのですが、
>当初はUsogresを利用するつもりはなくて（というか、存在を知りませんでした）
>いままで気がつきませんでした。
>テーブル定義中で DEFAULT 'now' などとしているのもダメですね。
>
>確認できてすっきりしました。ありがとうございました。

それ以外に、trigger や select で関数を呼んでいて、その関数が
更新を行なうようなケースも、要注意です。（SQLベースレプリケーションの
実装方法によりますが。。）

>
>
>目的としては負荷分散ではなくフェールオーバのためを意図していましたので、
>まずはRAID1にてサーバーを運用することと、ベタではありますが、
>HDD以外のハードウェア障害に対しては代わりのサーバーを用意しておいて
>障害時には切り替える（HDDを手で入れ替えorデータをコピー）という方法で、
>また負荷分散はDBサーバー以外の機能を別のマシンに移すといった方法にて
>間に合いそうです。

　フェールオーバーした結果、データベースの中身が異なってしまうような
ケースは避ける必要があります。上記のような now() が derfault 句で
使われているケースなど。。
アプリケーション的（システム的）に、その程度の誤差は「無視OK」という
なら別ですが。。

>
>レプリケーションを利用しようと考える場合には
>設計時からちゃんと考えておく必要がありますね。

　どんな場合でも、データベースシステム構築に限らず「設計時点から、
要件定義が確実に実装されているか、出来るかの確認」は重要ですね。
>
> * * *
>
>ところで、クエリベースではないレプリケーションの実装というのは
>やはり相当複雑で難しいことなのですよね？

　いえいえ、それほど難しいものでは無いでしょう。例えば、ログベースの
レプリケーションなど：この場合、非同期レプリケーションですが。

　難しいのは「マルチマスタでの同期レプリケーション」です。おまけに、
負荷分散まで。。それを実現する、たとえば一つの方法として「SQLベース
レプリケーション」があります。ただし、現時点では万能ではありません。
マルチマスタ 同期レプリケーションでは、常に、独立なインスタンス間で、
ACIDを保障しながらデータベース内容のリアルタイムな同期をとるというのが、
難しい〜。。？＊＋＠「＾-＾。。

>その関連でRAID1の処理ロジックを知りたいなと思ったのですが、
>適当なページをみつけることができませんでした。
>LinuxのソフトウェアRAIDのドキュメントかソースを追っかけると
>少し理解が深められるかもしれないので、
>機会をみてちょっとみてみたいと思っています。

　どこまで、ご存知になられたいかによりますが、
　RAID level-1 （ミラーリング）のアルゴリズムは、単純です。原理は、
受け取ったディスク I/O 要求を、２つの独立なデバイスに渡すだけです。
また、この機能をどこで（system-call, device-driver, RAID-controller, etc..）
どのように実装するか。どこまで結果をチェックするか。キャッシングを
どうするか、等によって、さまざまの製品があります。

「1つのミラー化された（RAI Level-1）ディスクボリュームを複数のサーバーで
共有（接続）し、互いに同時に Read/Write する。かつ、データの一貫性を保障」
というのが、「マルチマスタでの同期レプリケーション」に似た状態でしょうか。。
　
>

---------------------------------
Y.shimada





From tanaka.hideki ＠ future.co.jp  Thu May 22 13:50:09 2003
From: tanaka.hideki ＠ future.co.jp (tanaka.hideki ＠ future.co.jp)
Date: Thu, 22 May 2003 13:50:09 +0900
Subject: [pgsql-jp: 30023] pgsqlを使用してストアドプロシージャを作成および実行する方法(再送）
Message-ID: <D76C00438333264F8D4B4409D9EF2F15E7C808@003POST.future.co.jp>

お世話になっております。
 
OS:Redhat Linux 
DB:PostgreSQL7.2 
 
あるテーブルに大量にデータを挿入または更新するストプロを作りたいと思います。
Postgreでは、ルール、関数などにより、サーバサイドのプログラムが開発できると
ありますが、オラクルでいうところのストアドプロシージャに相当するものはあるので
しょうか？
 
PGSQLを使用すると関数をつくることができるとありますが、関数だと、他のSQLと
一緒に使用するかたちになると思います。
 
単体で動かせる仕組みがありましたら教えて下さい。
 
以上


From kishi ＠ b-b-net.com  Thu May 22 17:19:01 2003
From: kishi ＠ b-b-net.com (Emiko Kishi)
Date: Thu, 22 May 2003 17:19:01 +0900
Subject: [pgsql-jp: 30024] Re: 使用しているファイルサイズを調べたい
In-Reply-To: <20030515.154804.35663049.sugita@sra.co.jp>
Message-ID: <MHEMLLOEBIEENMDDBMHJGEAOCNAA.kishi@b-b-net.com>

おつかれさまです、岸です。
いつもお世話になっております。

先週、表題の件でアドバイスをいただいた後、
ダミーデータの投入・実測値計算を行い、論理値と比較してみました。

ですが、実測値が論理値を大きく上回ってしまいました。
あまりにも差が大きいので、どこかが間違っているのだと思います。
いろいろと理由を考えたり調べたりしてみたのですが、
ハッキリした原因は突き止められませんでした。
# 大きなサイズのtextフィールドが圧縮されていないようにも
# 思えるのですが、そんなことってあるのですか？

なにか手がかりに思い当たられる方がいらっしゃいましたら、
アドバイスをいただけませんか？

環境は、PostgreSQL 7.2.3 (FreeBSD 4.7 / Apache 1.3.27)です。

以下に、行った手順を書きます（長文で失礼します）：

ダミーデータは、PKEYを設定した状態のテーブルに
1件のINSERTを行うSQLを、スクリプトでループさせて投入しました。
全部で1539件を投入したところで一旦REINDEXを行いました。
（最後の数件は、運用予定のperlCGIでフォームから入力しました）

テーブル「sample」は下記の通りです。
論理値計算の割り算は、最終的な結果が大きくなるように丸めました。
Column  Type                  投入データ         論理値計算
======= ===================== ================== ================
num1    integer               連番、PKEY                        4
num2    integer               数値        10byte                4
char1   character varying(12) 半角英数字  12byte        12+4 = 16
text1   text                  全角文字 0〜14byte        12+4 = 16
text2   text                  全角文字    40byte        40+4 = 44
text3   text                  全角文字  2000byte (2000+4)/30 = 67
bool1   boolean                                                 1
bool2   boolean                                                 1
-----------------------------------------------------------------
                                    論理値合計                153
                                    フィールド間       4 * 7 = 28
                                    行ヘッダ                   32
                                    NULLビットマスク            4
                                    タプルへのポインタ          4
                                    -----------------------------
                                    1タプルのサイズ           221
                                    1ブロックのタプル数        37
                                    1539件のブロック数         42

インデックス「sample_pkey」は下記の通りです。
Column  Type                  投入データ         論理値
======= ===================== ================== ================
num1    integer               連番、PKEY                        4
-----------------------------------------------------------------
                                    論理値合計                  4
                                    フィールド間                0
                                    行ヘッダ                   32
                                    NULLビットマスク            4
                                    タプルへのポインタ          4
                                    -----------------------------
                                    1タプルのサイズ            44
                                    1ブロックのタプル数       186
                                    1539件のブロック数          9

VACUUM ANALYZEした直後に、pg_classでタプルとページを調べました。
relname                  reltuples relpages
======================== ========= ========
sample                        1539       42
sample_pkey                   1539        6

indexはともかくとして、概ね予想通りと思っていたのですが、
[pgsql-jp: 29895]で教えていただいたスクリプトを見て、
TOASTテーブルも考慮しなければならないと思い、調べてみました。

relname                  reltuples relpages
======================== ========= ========
pg_toast_sampleのoid          3072      793
pg_toast_sampleのoid_idx      3072       20

これを足すと、論理値と比較してあまりにもサイズが大きすぎるので、
以下のようなSQL文でデータのサイズを調べてみました。

select avg(octet_length(text3)), avg(char_length(text3)) from sample;
       avg       |       avg
-----------------+-----------------
 1997.6179337232 | 1997.6179337232

# 2000より少し少ないのは、手入力した数件のデータが
# 2000byteよりもだいぶ少なかったためと思われます。
# このSQL文は、過去ログのtextの圧縮についての投稿を参考にしました。
# http://ml.postgresql.jp/pipermail/pgsql-jp/2002-October/002880.html

textの圧縮が行われていないように思えるのですが、本当にそうなのでしょうか
？
（圧縮をさせないような設定は何も行っていません）
それとも、この結果が正しくて論理値の計算の方が間違っているのでしょうか？

もっと根本的なところがわかっていないのかも、と思っています。

ここを勉強するとわかるよ、というポインタ等でもかまいませんので、
手がかりを教えていただけませんか？

よろしくお願いします。

-----
岸恵美子 kishi ＠ b-b-net.com





From yiwakiri ＠ st.rim.or.jp  Thu May 22 17:32:08 2003
From: yiwakiri ＠ st.rim.or.jp (Youichi Iwakiri)
Date: Thu, 22 May 2003 17:32:08 +0900
Subject: [pgsql-jp: 30025] Re: 使用しているファイルサイズを調べたい
In-Reply-To: <MHEMLLOEBIEENMDDBMHJGEAOCNAA.kishi@b-b-net.com>
References: <20030515.154804.35663049.sugita@sra.co.jp>
	<MHEMLLOEBIEENMDDBMHJGEAOCNAA.kishi@b-b-net.com>
Message-ID: <200305220832.RAA15149@mail2.rim.or.jp>

いわきりです

Emiko Kishi wrote in <MHEMLLOEBIEENMDDBMHJGEAOCNAA.kishi ＠ b-b-net.com> :
>環境は、PostgreSQL 7.2.3 (FreeBSD 4.7 / Apache 1.3.27)です。

>select avg(octet_length(text3)), avg(char_length(text3)) from sample;
>       avg       |       avg
>-----------------+-----------------
> 1997.6179337232 | 1997.6179337232
>
># 2000より少し少ないのは、手入力した数件のデータが
># 2000byteよりもだいぶ少なかったためと思われます。
># このSQL文は、過去ログのtextの圧縮についての投稿を参考にしました。
># http://ml.postgresql.jp/pipermail/pgsql-jp/2002-October/002880.html
>
>textの圧縮が行われていないように思えるのですが、本当にそうなのでしょうか
>？

versionが7.2以降なので、動作としては正しいです。

参考URL

http://ml.postgresql.jp/pipermail/pgsql-jp/2002-March/000168.html
>1) データ圧縮
>
>        「PostgreSQL 完全攻略ガイド 第 3 版」の P.94〜95。
>
>	    7.2 では octet_length の戻り値が変更され圧縮された値でなく、データ
>            の実際のバイト数となっていることに注意。

と過去のメールで、私も知りました。

-- 
Youichi Iwakiri



From sakata.tetsuo ＠ lab.ntt.co.jp  Thu May 22 17:44:58 2003
From: sakata.tetsuo ＠ lab.ntt.co.jp (Tetsuo SAKATA)
Date: Thu, 22 May 2003 17:44:58 +0900
Subject: [pgsql-jp: 30026] Statistical Softwares (was re PostgreSQL on R)
References: <20030521.093436.607955858.nakama@ki.rim.or.jp>
		<3ECADCF1.E7153412@lab.ntt.co.jp> <20030521.122146.640900813.nakama@ki.rim.or.jp>
Message-ID: <3ECC8E0A.9F461E12@lab.ntt.co.jp>

こんにちは．坂田@横須賀です．

Ei-ji Nakama さんwrote:
> Wed, 21 May 2003 10:57:05 +0900
> Tetsuo SAKATA <sakata.tetsuo ＠ lab.ntt.co.jp> wrote.
> > 坂田@横須賀(Rユーザ歴3年...)です．
> 
> > あと，お節介ですが；
> > http://www.nakama.ne.jp/memo/cran-R/Rdbi.PgSQL/index.html
> > ↑のページに，"R Data Import/Export"を参照しておくと，
> > 何をやっているのかが分かりやすくなって，親切ではないかと思いました．
> 
> 加えておきました。
> # 日本語ドキュメントあったんですね。(^^;

修正後のページ，拝見しました．
# "坂田@横須賀(Rユーザ歴3年...)"の発言なんですね．．． (^.^;
日本語ドキュメントの存在は，ぼくも知りませんでした．
重宝しそうです．ありがとうございます．

> > #Rが流行っていない，というのは事実誤認かなぁ．
> 
> うーん、どうなんでしょうね。?

松永さんからも，同趣旨のコメントを頂いていますね．

松永 均 さんwrote:
> > #確かに，SPSSのような商用の統計パッケージほど有名では
> > #ないのでしょうが，基本的な処理は一通りかけるし，
> 
> debian には R(S like) も pspp(spss compatible) もパッケージがありますね。
> 実際のところ、どっちが普及してるんでしょ。

この際ですから，"PSPP"で日本語のサイトをググってみました．
ざっと見た範囲では，PSPP の使い方等を具体的に解説している
サイトは見つかりませんでした．(Rについては，そういうサイトが
複数ありますね)

R/PSPPに限れば，前者の方が普及していると思って良いでしょう．
ですが，SPSS(オリジナル)の方は，社会科学関係(心理学とか
マーケティングとか)を中心にS(オリジナル)以上に普及しているようですから，
PSPPの実装が進めば，状況は逆転するかもしれない，と思っています．

では．
-- 
	NTT サイバースペース研究所	sakata.tetsuo ＠ lab.ntt.co.jp
	坂田　哲夫			Tel: 046-859-2765
					Fax: 046-859-2768
Tetsuo SAKATA, Yokosuka JAPAN.


From kishi ＠ b-b-net.com  Thu May 22 17:51:42 2003
From: kishi ＠ b-b-net.com (Emiko Kishi)
Date: Thu, 22 May 2003 17:51:42 +0900
Subject: [pgsql-jp: 30027] Re: 使用しているファイルサイズを調べたい
In-Reply-To: <200305220832.RAA15149@mail2.rim.or.jp>
Message-ID: <MHEMLLOEBIEENMDDBMHJAEBDCNAA.kishi@b-b-net.com>

おつかれさまです、岸です。
いつもお世話になっております。

いわきりさま、早速の返信ありがとうございます。

> いわきりです
>
> Emiko Kishi wrote in
> <MHEMLLOEBIEENMDDBMHJGEAOCNAA.kishi ＠ b-b-net.com> :
> >環境は、PostgreSQL 7.2.3 (FreeBSD 4.7 / Apache 1.3.27)です。
>
> >select avg(octet_length(text3)), avg(char_length(text3)) from sample;
> >       avg       |       avg
> >-----------------+-----------------
> > 1997.6179337232 | 1997.6179337232
> >
> ># 2000より少し少ないのは、手入力した数件のデータが
> ># 2000byteよりもだいぶ少なかったためと思われます。
> ># このSQL文は、過去ログのtextの圧縮についての投稿を参考にしました。
> ># http://ml.postgresql.jp/pipermail/pgsql-jp/2002-October/002880.html
> >
> >textの圧縮が行われていないように思えるのですが、本当にそうなのでしょ
う
> か
> >？
>
> versionが7.2以降なので、動作としては正しいです。

ということは、このSQL文では本当のデータがどうなっているか
調べることはできないということですよね。
# ファイルサイズが見れればなぁ・・・

情報ありがとうございました。

-----
岸恵美子 kishi ＠ b-b-net.com





From sugita ＠ sra.co.jp  Thu May 22 18:00:09 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Thu, 22 May 2003 18:00:09 +0900 (JST)
Subject: [pgsql-jp: 30028] Re: 使用しているファイルサイズを調べたい
In-Reply-To: <MHEMLLOEBIEENMDDBMHJAEBDCNAA.kishi@b-b-net.com>
References: <200305220832.RAA15149@mail2.rim.or.jp>
	<MHEMLLOEBIEENMDDBMHJAEBDCNAA.kishi@b-b-net.com>
Message-ID: <20030522.180009.48511623.sugita@sra.co.jp>

  杉田です。

From: "Emiko Kishi" <kishi ＠ b-b-net.com>
Subject: [pgsql-jp: 30027] Re: 使用しているファイルサイズを調べたい
Date: Thu, 22 May 2003 17:51:42 +0900

;;; # ファイルサイズが見れればなぁ・・・

    contrib/dbsize

    ====  README.dbsize  =====
    This module contains two functions that report the size of a given
    database or relation.  E.g.,

    SELECT database_size('template1');
    SELECT relation_size('pg_class');

    These functions report the actual file system space.  Thus, users can
    avoid digging through the details of the database directories.

    Copy this directory to contrib/dbsize in your PostgreSQL source tree.
    Then just run make; make install.

というのもあります。7.3 のマニュアルの Chapter 11. Monitoring Disk Usage に少
し説明があります。


Kenji Sugita                                      


From kishi ＠ b-b-net.com  Thu May 22 18:46:45 2003
From: kishi ＠ b-b-net.com (Emiko Kishi)
Date: Thu, 22 May 2003 18:46:45 +0900
Subject: [pgsql-jp: 30029] Re: 使用しているファイルサイズを調べたい
In-Reply-To: <20030522.180009.48511623.sugita@sra.co.jp>
Message-ID: <MHEMLLOEBIEENMDDBMHJAEBKCNAA.kishi@b-b-net.com>

おつかれさまです、岸です。
いつもお世話になっております。

杉田さま、返信ありがとうございます。

>   杉田です。
>
> ;;; # ファイルサイズが見れればなぁ・・・
>
>     contrib/dbsize
[中略]
> というのもあります。7.3 のマニュアルの Chapter 11. Monitoring
> Disk Usage に少し説明があります。
>

たどたどしく英文を読むと、
「実際のファイルシステムスペースを報告する」
「ユーザーはデータベースディレクトリを掘り下げるのを避けられる」
というモジュールだとのこと。

おおっ。調べてみます。

情報ありがとうございます。

-----
岸恵美子 kishi ＠ b-b-net.com





From zensyo ＠ ann.tama.kawasaki.jp  Fri May 23 00:23:15 2003
From: zensyo ＠ ann.tama.kawasaki.jp (zensyo ＠ ann.tama.kawasaki.jp)
Date: Fri, 23 May 2003 00:23:15 +0900 (JST)
Subject: [pgsql-jp: 30030] Re: コネクションプールが最大数を越えます
In-Reply-To: <3ECAF19A.8020008@palmyra.ne.jp>
References: <3ECAF19A.8020008@palmyra.ne.jp>
Message-ID: <20030523.002315.70216139.zensyo@ann.tama.kawasaki.jp>

鈴木＠inetdです。

From: 末光美恵 <zenobia ＠ palmyra.ne.jp>
Subject: [pgsql-jp: 30018] コネクションプールが最大数を越えます
Date: Wed, 21 May 2003 12:25:14 +0900
Message-ID: <3ECAF19A.8020008 ＠ palmyra.ne.jp>

> 解決方法として試みたのは
> １．アプリケーションプログラムで必ずコネクションを close する
> 　　当たり前ですが、これが信頼できないので、溜まったコネクションプールを
> 　　破棄するのが今回の命題です。

途中省略

> 無駄なコネクションプールを破棄する方法を教えて下さい。

うちでは仕方ないのでdelegateを途中に挟んでtimeout処理をさせるようにし
ています。

client --------(5432)-> delegate -------(5431)-> postmaster
  (内はポート番号)

delegateの起動はこんな感じです。
  delegated -P5432 SERVER=tcprelay://dbserver.example.com:5431 TIMEOUT=io:60

上記例では60秒間通信が行われていないとコネクションを切断します。
コネクションを切断したことはpostmasterのログには即座に出ます。psqlでは
タイムアウト後にコマンドを実行すると、切断された旨表示されます。
（psqlは一旦認証を済ますと、再接続時には自動的に認証してくれるんですね）

postmasterのポートをデフォルトから変更するとpg_ctlが結構あやしい動きに
なってしまうようです。pg_ctl start を実行するときに-Wオプションが必要
でした。

でわ。




From sugita ＠ sra.co.jp  Fri May 23 03:55:53 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Fri, 23 May 2003 03:55:53 +0900 (JST)
Subject: [pgsql-jp: 30031] Re: コネクションプールが最大数を越えます
In-Reply-To: <20030523.002315.70216139.zensyo@ann.tama.kawasaki.jp>
References: <3ECAF19A.8020008@palmyra.ne.jp>
	<20030523.002315.70216139.zensyo@ann.tama.kawasaki.jp>
Message-ID: <20030523.035553.104051532.sugita@sra.co.jp>

  杉田です。

From: zensyo ＠ ann.tama.kawasaki.jp
Subject: [pgsql-jp: 30030] Re: コネクションプールが最大数を越えます
Date: Fri, 23 May 2003 00:23:15 +0900 (JST)

;;; postmasterのポートをデフォルトから変更するとpg_ctlが結構あやしい動きに
;;; なってしまうようです。pg_ctl start を実行するときに-Wオプションが必要
;;; でした。

  以下の => です。postgresql.conf で変更している場合には、このファイルを見て、
そのポートを使うように pg_ctl を変更することで回避できます。

    ====  pg_ctl より  ====
    # FIXME:  This is horribly misconceived.
    # 1) If password authentication is set up, the connection will fail.
    # 2) If a virtual host is set up, the connection may fail.
    # 3) If network traffic filters are set up tight enough, the connection
    #    may fail.
    # 4) When no Unix domain sockets are available, the connection will
    #    fail.  (Using TCP/IP by default ain't better.)
=>  # 5) When a different port is configured, the connection will fail
=>  #    or go to the wrong server.
    # 6) If the dynamic loader is not set up correctly (for this user/at
    #    this time), psql will fail (to find libpq).
    # 7) If psql is misconfigured, this may fail.


Kenji Sugita                                      


From suyama.shozo ＠ jp.panasonic.com  Fri May 23 08:57:27 2003
From: suyama.shozo ＠ jp.panasonic.com (Shozo Suyama)
Date: Fri, 23 May 2003 08:57:27 +0900
Subject: [pgsql-jp: 30032] Re: pgsqlを使用してストアドプロシージャを作成および実行する方法(再送）
References: <D76C00438333264F8D4B4409D9EF2F15E7C808@003POST.future.co.jp>
Message-ID: <002401c320bd$e5e6ecd0$c239490a@sdc.pe>

陶山です。

求めている答えと違うかもしれませんが、PL/pgSQL というものを使用して関数を作成
し、SELECTで使えば使用できると思いますよ。

以下、PL/pgSQL の参考URLです。
http://www.postgresql.jp/document/pg721doc/programmer/plpgsql.html

*****************************************
陶山　正蔵  （SUYAMA SHOZO)

E-Mail suyama.shozo ＠ jp.panasonic.com
*****************************************
----- Original Message ----- 
From: <tanaka.hideki ＠ future.co.jp>
To: <pgsql-jp ＠ ml.postgresql.jp>
Sent: Thursday, May 22, 2003 1:50 PM
Subject: [pgsql-jp: 30023] pgsqlを使用してストアドプロシージャを作成および実行す
る方法(再送）


> お世話になっております。
>
> OS:Redhat Linux
> DB:PostgreSQL7.2
>
> あるテーブルに大量にデータを挿入または更新するストプロを作りたいと思います。
> Postgreでは、ルール、関数などにより、サーバサイドのプログラムが開発できると
> ありますが、オラクルでいうところのストアドプロシージャに相当するものはあるので
> しょうか？
>
> PGSQLを使用すると関数をつくることができるとありますが、関数だと、他のSQLと
> 一緒に使用するかたちになると思います。
>
> 単体で動かせる仕組みがありましたら教えて下さい。
>
> 以上



From tanaka.hideki ＠ future.co.jp  Fri May 23 10:44:24 2003
From: tanaka.hideki ＠ future.co.jp (tanaka.hideki ＠ future.co.jp)
Date: Fri, 23 May 2003 10:44:24 +0900
Subject: [pgsql-jp: 30033] Re: pgsqlを使用してストアドプロシージャを作成および実行する方法(再送）
Message-ID: <D76C00438333264F8D4B4409D9EF2F15E7C81D@003POST.future.co.jp>

田中です。

OracleのPL/SQLで作成したストプロのように、EXECUTE プロシージャ名というわけには
いかないのですね。

ありがとうございました。

-----Original Message-----
From: Shozo Suyama [mailto:suyama.shozo ＠ jp.panasonic.com] 
Sent: Friday, May 23, 2003 8:57 AM
To: pgsql-jp ＠ ml.postgresql.jp
Subject: [pgsql-jp: 30032] Re: pgsqlを使用してストアドプロシージャを作成および実行する方法(再送）


陶山です。

求めている答えと違うかもしれませんが、PL/pgSQL というものを使用して関数を作成
し、SELECTで使えば使用できると思いますよ。

以下、PL/pgSQL の参考URLです。
http://www.postgresql.jp/document/pg721doc/programmer/plpgsql.html

*****************************************
陶山　正蔵  （SUYAMA SHOZO)

E-Mail suyama.shozo ＠ jp.panasonic.com
*****************************************
----- Original Message ----- 
From: <tanaka.hideki ＠ future.co.jp>
To: <pgsql-jp ＠ ml.postgresql.jp>
Sent: Thursday, May 22, 2003 1:50 PM
Subject: [pgsql-jp: 30023] pgsqlを使用してストアドプロシージャを作成および実行す
る方法(再送）


> お世話になっております。
>
> OS:Redhat Linux
> DB:PostgreSQL7.2
>
> あるテーブルに大量にデータを挿入または更新するストプロを作りたいと思います。
> Postgreでは、ルール、関数などにより、サーバサイドのプログラムが開発できると
> ありますが、オラクルでいうところのストアドプロシージャに相当するものはあるので
> しょうか？
>
> PGSQLを使用すると関数をつくることができるとありますが、関数だと、他のSQLと
> 一緒に使用するかたちになると思います。
>
> 単体で動かせる仕組みがありましたら教えて下さい。
>
> 以上



From zensyo ＠ ann.tama.kawasaki.jp  Fri May 23 10:50:41 2003
From: zensyo ＠ ann.tama.kawasaki.jp (zensyo ＠ ann.tama.kawasaki.jp)
Date: Fri, 23 May 2003 10:50:41 +0900 (JST)
Subject: [pgsql-jp: 30034] Re: コネクションプールが最大数を越えます
In-Reply-To: <20030523.100915.78765404.zensyo@ann.tama.kawasaki.jp>
References: <20030523.002315.70216139.zensyo@ann.tama.kawasaki.jp>
	<20030523.035553.104051532.sugita@sra.co.jp>
Message-ID: <20030523.105041.115962683.zensyo@ann.tama.kawasaki.jp>

鈴木です。

>   杉田です。
> 
> From: zensyo ＠ ann.tama.kawasaki.jp
> Subject: [pgsql-jp: 30030] Re: コネクションプールが最大数を越えます
> Date: Fri, 23 May 2003 00:23:15 +0900 (JST)
> 
> ;;; postmasterのポートをデフォルトから変更するとpg_ctlが結構あやしい動きに
> ;;; なってしまうようです。pg_ctl start を実行するときに-Wオプションが必要
> ;;; でした。
> 
>   以下の => です。postgresql.conf で変更している場合には、このファイルを見て、
> そのポートを使うように pg_ctl を変更することで回避できます。

あらら。postgresql.confを読んでくれないんですね。
良く見ればスクリプトだからすぐわかったのに、なぜかぜんぜんpg_ctlを開け
て見もしませんでした。

どうもありがとうございました。

# 7) If psql is misconfigured, this may fail.
!           if "$PGPATH/psql" -l >/dev/null 2>&1

# 7) If psql is misconfigured, this may fail.
!           if "$PGPATH/psql" --port 5431 -l >/dev/null 2>&1

こんな感じに。
# ほんとはpostgresql.confから取り出せばいいんだと思いますが、あまりポー
ト変えることもないので、、、



From hotta ＠ net-newbie.com  Fri May 23 13:21:01 2003
From: hotta ＠ net-newbie.com (HOTTA Michihide)
Date: Fri, 23 May 2003 13:21:01 +0900
Subject: [pgsql-jp: 30035] Re: 7.3.2 ドキュメント
In-Reply-To: <E19I09d-0000mk-00@smtp02.fields.gol.com>
References: <E19I09d-0000mk-00@smtp02.fields.gol.com>
Message-ID: <20030523131426.B5B5.HOTTA@net-newbie.com>

堀田です。遅いフォローですが、

From: Ishikawa Toshiyuki <tosiyuki ＠ gol.com>
Subject: [pgsql-jp: 29996] 7.3.2 ドキュメント
Date: 2003/05/20 15:00:04

> JPUG 書籍・文書関連分科会の石川です。
> 
> 現在分科会の作業結果として 7.2 ベースのドキュメントを Web
> で公開しておりますが、SRA さんが PowerGres 開発にあたって、
> これを基に独自でリリース 7.3 で変更・追加された部分を翻訳
> してPostgreSQL 7.3.2の日本語ドキュメントを作成，製品に添付
> 商用配布されてきました。コミュニティの成果をベースにしてい
> るという観点からも、成果をコミュニティに還元するため、7.3.2
> の日本語ドキュメントを JPUG に寄贈したいとのお申し出でがあり、
> 有難くお受けいたしました。

ぱちぱちぱち〜♪

> 成果は sgml のソースで頂きましたので、html と man ページを
> 生成し、本日以下の URL で公開しました。この日本語マニュアル
> が皆様のお役に立つことを願っています。
> 
> http://www.postgresql.jp/document/pg732doc/index.html

当方のマニュアル検索サイトも 7.3.2 に追従しました。

  http://search.net-newbie.com/

# PostgreSQL と PHP のインデックスを分けてたのに、いつのまにか
# 選択不能になっていたのも直しました。/etc/namazu/nmazurc を
# 消すだけでよかったのね…。
-- 
堀田 倫英 <hotta ＠ net-newbie.com> <http://www.net-newbie.com>


From toshitaka.iso ＠ hp.com  Fri May 23 16:03:17 2003
From: toshitaka.iso ＠ hp.com (Iso, Toshitaka)
Date: Fri, 23 May 2003 16:03:17 +0900
Subject: [pgsql-jp: 30036] 「vacuum」と「analyze」と「vacuum analyze」と「vacuum full」の違いについて
Message-ID: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E021CC8D6@tkoexc02.asiapacific.cpqcorp.net>

お世話になります。

VacuumとAnalyze、Vacuum Analyzeの違いについてお教え下さい。

【PostgreSQLのバージョン＝7.2.1】



あるテーブル（データ件数＝9万件ほど）があります。
このテーブル構造は以下のような感じで、lockkbnとlocknoで
Primary Keyとなっております。
 lockkbn      | character(4)                 | not null
 lockno       | character varying(40)      | not null
 lockcndtn   | character(1)                  |
 lockstrtdt   | timestamp with time zone |
 lockenddt   | timestamp with time zone |

しばらくの間はlockkbnとlockcndtnで検索を行うと、
Primary keyを使用してIndex Scanが走っていたのですが、
データ件数が増えるにつれSeq Scanが走るようになりました。

ここで、不要レコードを削除し、vacuum analyzeをかけるという
ことになったのですが、
select * from pg_class where relname='tbl_hoge'
のreltupleの値がcount(*)で検索した際のレコード件数と
違い膨大な数をもっており相変わらずSeq Scanでした。

## vacuum analyze後の結果
実際のレコード件数＝129件
reltupleの値＝89762（単位は「件」?）

ところが、analyzeだけを実行したところ、
pg_classの当該テーブルのreltuple値がDeleteしたテーブルの
レコード件数と一致し、Index Scanをしてくれるようになりました。

## analyze後の結果
実際のレコード件数＝129件
reltupleの値＝129（単位は「件」?）


長々書きましたがここで質問です。

「vacuum」と「analyze」と「vacuum analyze」と「vacuum full」の違いについて
確認させてください。

私の認識とマニュアルで確認結果です。

【vacuum】
削除済みレコードを空き領域にする。統計情報は更新しない。

【analyze】
統計情報の更新。削除済みレコードの空き領域処理はしない。

【Vacuum Analyze】
VacuumとAnalyzeを実行？
（実際は統計情報は更新されていませんでした）

【Vacuum full】
空きデータ領域をデフラグ？



上記認識に間違いがあればご指摘いただけないでしょうか？
現状はVacuum analyzeを1日一回、analyzeのみを1日一回
実行しています。

以上です。


From tosiyuki ＠ gol.com  Fri May 23 18:45:55 2003
From: tosiyuki ＠ gol.com (Ishikawa Toshiyuki)
Date: Fri, 23 May 2003 18:45:55 +0900
Subject: [pgsql-jp: 30037] Re: 7.3.2 ドキュメント
In-Reply-To: <20030523131426.B5B5.HOTTA@net-newbie.com>
References: <20030523131426.B5B5.HOTTA@net-newbie.com>
Message-ID: <E19J96T-0008Gb-00@smtp01.fields.gol.com>

石川です。

お久しぶりです。どうも有難うございます。
7.4 翻訳開始の暁になぜひ参加してください。

HOTTA Michihide <hotta ＠ net-newbie.com> wrote:

> 堀田です。遅いフォローですが、
> 
> From: Ishikawa Toshiyuki <tosiyuki ＠ gol.com>
> Subject: [pgsql-jp: 29996] 7.3.2 ドキュメント
> Date: 2003/05/20 15:00:04
> 
> > JPUG 書籍・文書関連分科会の石川です。
> > 
> > 現在分科会の作業結果として 7.2 ベースのドキュメントを Web
> > で公開しておりますが、SRA さんが PowerGres 開発にあたって、
> > これを基に独自でリリース 7.3 で変更・追加された部分を翻訳
> > してPostgreSQL 7.3.2の日本語ドキュメントを作成，製品に添付
> > 商用配布されてきました。コミュニティの成果をベースにしてい
> > るという観点からも、成果をコミュニティに還元するため、7.3.2
> > の日本語ドキュメントを JPUG に寄贈したいとのお申し出でがあり、
> > 有難くお受けいたしました。
> 
> ぱちぱちぱち〜♪
> 
> > 成果は sgml のソースで頂きましたので、html と man ページを
> > 生成し、本日以下の URL で公開しました。この日本語マニュアル
> > が皆様のお役に立つことを願っています。
> > 
> > http://www.postgresql.jp/document/pg732doc/index.html
> 
> 当方のマニュアル検索サイトも 7.3.2 に追従しました。
> 
>   http://search.net-newbie.com/
> 
> # PostgreSQL と PHP のインデックスを分けてたのに、いつのまにか
> # 選択不能になっていたのも直しました。/etc/namazu/nmazurc を
> # 消すだけでよかったのね…。
> -- 
> 堀田 倫英 <hotta ＠ net-newbie.com> <http://www.net-newbie.com>



From sugita ＠ sra.co.jp  Sat May 24 01:55:13 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Sat, 24 May 2003 01:55:13 +0900 (JST)
Subject: [pgsql-jp: 30038] Re: 「vacuum 」と「analyze」と「vacuum analyze」と「vacuum full」の違いについて
In-Reply-To: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E021CC8D6@tkoexc02.asiapacific.cpqcorp.net>
References: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E021CC8D6@tkoexc02.asiapacific.cpqcorp.net>
Message-ID: <20030524.015513.112623836.sugita@sra.co.jp>

  杉田です。

From: "Iso, Toshitaka" <toshitaka.iso ＠ hp.com>
Subject: [pgsql-jp: 30036] 「vacuum 」と「analyze」と「vacuum analyze」と「vacuum full」の違いについて
Date: Fri, 23 May 2003 16:03:17 +0900

;;; VacuumとAnalyze、Vacuum Analyzeの違いについてお教え下さい。
;;; 
;;; 【PostgreSQLのバージョン＝7.2.1】
;;; 
;;; 
;;; 
;;; あるテーブル（データ件数＝9万件ほど）があります。
;;; このテーブル構造は以下のような感じで、lockkbnとlocknoで
;;; Primary Keyとなっております。
;;;  lockkbn      | character(4)                 | not null
;;;  lockno       | character varying(40)      | not null
;;;  lockcndtn   | character(1)                  |
;;;  lockstrtdt   | timestamp with time zone |
;;;  lockenddt   | timestamp with time zone |
;;; 
;;; しばらくの間はlockkbnとlockcndtnで検索を行うと、
;;; Primary keyを使用してIndex Scanが走っていたのですが、
;;; データ件数が増えるにつれSeq Scanが走るようになりました。
;;; 
;;; ここで、不要レコードを削除し、vacuum analyzeをかけるという
;;; ことになったのですが、
;;; select * from pg_class where relname='tbl_hoge'
;;; のreltupleの値がcount(*)で検索した際のレコード件数と
;;; 違い膨大な数をもっており相変わらずSeq Scanでした。

  count(*) と reltuples の大幅な食い違いは、例えば、削除されたレコードが多く、
偏りがある場合に、ANALYZE をしたときに発生します。ANALYZE は、サンプリングし外
挿するからです。

  FSM が正しく調整された元で、VACUUM を適切に実行してあれば、ANALYZE 後の
reltuples の値は、誤差程度とみなせるようになると思われます。

;;; ## vacuum analyze後の結果
;;; 実際のレコード件数＝129件

  VACUUM ANALYZE 後の count() による実際の件数でしょうか? そうすると最初の方で
は、データ件数が 9 万程と言われているのと合いません。

;;; reltupleの値＝89762（単位は「件」?）

  型が real なので、その精度での件数です。

;;; ところが、analyzeだけを実行したところ、
;;; pg_classの当該テーブルのreltuple値がDeleteしたテーブルの
;;; レコード件数と一致し、Index Scanをしてくれるようになりました。
;;; 
;;; ## analyze後の結果
;;; 実際のレコード件数＝129件
;;; reltupleの値＝129（単位は「件」?）

  delete した件数に一致したというのは疑問に思いますが、極端に違うと考える事に
します。

  RedHat の pg_filedump で、テーブルのファイルをダンプして、どのような分布になっ
ているか調べ、外挿されて上記のように成り得るかを確認するのはどうでしょう?

  pg_filedump は、RedHat の web page の search で探せます。

;;; 長々書きましたがここで質問です。
;;; 
;;; 「vacuum」と「analyze」と「vacuum analyze」と「vacuum full」の違いについて
;;; 確認させてください。
;;; 
;;; 私の認識とマニュアルで確認結果です。
;;; 
;;; 【vacuum】
;;; 削除済みレコードを空き領域にする。統計情報は更新しない。

  reltuples が正確な値となります。

;;; 【analyze】
;;; 統計情報の更新。削除済みレコードの空き領域処理はしない。

  reltuples には外挿値が入ります。

;;; 【Vacuum Analyze】
;;; VacuumとAnalyzeを実行？
;;; （実際は統計情報は更新されていませんでした）

  統計情報が更新されていないと判断されたのはどのよう事からですか?

;;; 【Vacuum full】
;;; 空きデータ領域をデフラグ？

  はい。不要なインデックスタプルも減ります。
  

Kenji Sugita                                      




From t-ishii ＠ sra.co.jp  Sat May 24 11:32:47 2003
From: t-ishii ＠ sra.co.jp (Tatsuo Ishii)
Date: Sat, 24 May 2003 11:32:47 +0900 (JST)
Subject: [pgsql-jp: 30039] LinuxWorldにおける久米孝氏の講演
Message-ID: <20030524.113247.104032706.t-ishii@sra.co.jp>

石井です．

先日開催されたLinuxWorldで，経済産業省の久米孝氏がPostgreSQLに言及され
たそうですが，どういう話かご存じの方，よかったら教えてください．

政府関係者が「PostgreSQL」を知っているのか，と驚いたと同時に，ちょっと
気になったもので．
--
Tatsuo Ishii


From yiwakiri ＠ st.rim.or.jp  Sat May 24 12:04:53 2003
From: yiwakiri ＠ st.rim.or.jp (Youichi Iwakiri)
Date: Sat, 24 May 2003 12:04:53 +0900
Subject: [pgsql-jp: 30040] Re: LinuxWorldにおける久米孝氏の講演
In-Reply-To: <20030524.113247.104032706.t-ishii@sra.co.jp>
References: <20030524.113247.104032706.t-ishii@sra.co.jp>
Message-ID: <200305240304.MAA28635@mail6.rim.or.jp>

いわきりです

Tatsuo Ishii wrote in <20030524.113247.104032706.t-ishii ＠ sra.co.jp> :
>先日開催されたLinuxWorldで，経済産業省の久米孝氏がPostgreSQLに言及され
>たそうですが，どういう話かご存じの方，よかったら教えてください．

http://slashdot.jp/comments.pl?sid=95904&cid=321971

#フィルターがかかってるかもしれませんが :)

-- 
Youichi Iwakiri



From t-ishii ＠ sra.co.jp  Sat May 24 12:22:08 2003
From: t-ishii ＠ sra.co.jp (Tatsuo Ishii)
Date: Sat, 24 May 2003 12:22:08 +0900 (JST)
Subject: [pgsql-jp: 30041] Re: LinuxWorldにおける久米孝氏の講演
In-Reply-To: <200305240304.MAA28635@mail6.rim.or.jp>
References: <20030524.113247.104032706.t-ishii@sra.co.jp>
	<200305240304.MAA28635@mail6.rim.or.jp>
Message-ID: <20030524.122208.78706067.t-ishii@sra.co.jp>

石井です．

> いわきりです
> 
> Tatsuo Ishii wrote in <20030524.113247.104032706.t-ishii ＠ sra.co.jp> :
> >先日開催されたLinuxWorldで，経済産業省の久米孝氏がPostgreSQLに言及され
> >たそうですが，どういう話かご存じの方，よかったら教えてください．
> 
> http://slashdot.jp/comments.pl?sid=95904&cid=321971

いえ，これを読んでどういう話か分からなかったので質問させていただいたの
ですが:-)

ここでは久米氏がPostgreSQLを「ポスグレ」と呼んでいることしか分かりませ
んでした．

# でまたそれを投稿者が「「ポスグレ」という言葉の使い方が、単に各種報告
# をお勉強して空想しているだけではなく、雰囲気をよく掴んでいると思いま
# した」なんて誉めている(?)のでやんなっちゃう．「ポスグレ」という用語
# を使っている人はPostgreSQLの事情通とみなすことができる，とでも思って
# いるのだろうか．
--
Tatsuo Ishii


From kgotoh ＠ cic-kk.co.jp  Sat May 24 14:01:00 2003
From: kgotoh ＠ cic-kk.co.jp (Kazumasa Gotoh)
Date: Sat, 24 May 2003 14:01:00 +0900 (JST)
Subject: [pgsql-jp: 30042] Re: LinuxWorldにおける久米孝氏の講演
In-Reply-To: <20030524.122208.78706067.t-ishii@sra.co.jp>
References: <20030524.113247.104032706.t-ishii@sra.co.jp>
	<200305240304.MAA28635@mail6.rim.or.jp>
	<20030524.122208.78706067.t-ishii@sra.co.jp>
Message-ID: <20030524.140100.41690045.kgotoh@cic-kk.co.jp>

話がまったくそれてしまいますが…

From: Tatsuo Ishii <t-ishii ＠ sra.co.jp>
Date: Sat, 24 May 2003 12:22:08 +0900 (JST)

> ここでは久米氏がPostgreSQLを「ポスグレ」と呼んでいることしか分かりませ
> んでした．
> 
> # でまたそれを投稿者が「「ポスグレ」という言葉の使い方が、単に各種報告
> # をお勉強して空想しているだけではなく、雰囲気をよく掴んでいると思いま
> # した」なんて誉めている(?)のでやんなっちゃう．「ポスグレ」という用語
> # を使っている人はPostgreSQLの事情通とみなすことができる，とでも思って
> # いるのだろうか．

石井さんは PostgreSQL を「ポスグレ」と呼ぶのは嫌だと感じている…
という話は以前にもありましたが、私もこの手の呼び方は嫌いです。

また、私はその他の、例えば「メアド」とか「串」、「鯖」などの呼び方も
大嫌いです。
オフィシャルまたはオフィシャルに近い場でこんな呼び方をする人には、
その人の知性または品性を疑いたくなってきます。

しかし、私の勤務先内でも「ポスグレ」と呼んでいる者は少なく
ありません。どうも彼らと話をしていると、この呼び方をするのが
「格好いい」と思っているような雰囲気を感じます。

いい年をした大人が… 場合によっては 50過ぎの者が… こんな呼び方を
大真面目な顔でしているのを聞くと、私には醜悪な響きにしか聞こえ
ないんですが…

しかしまぁ、そんな呼び方が多数派になったりすることもあるんでしょう。
個人的には残念ですけどね。

# PostgreSQL については、「ポストグレスキューエル」という呼び方では
# 会話の中で頻繁に使うには長すぎる。という意見はあるでしょうね。
# 短縮形で呼ぶとすると、「ポストグレス」が許容範囲かな。

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
(株) セントラル情報センター
                             後藤和政    kgotoh ＠ cic-kk.co.jp


From ken ＠ tydfam.jp  Sat May 24 16:20:01 2003
From: ken ＠ tydfam.jp (Yamada Ken Takeshi)
Date: Sat, 24 May 2003 16:20:01 +0900 (JST)
Subject: [pgsql-jp: 30043] Re: LinuxWorldにおける久米孝氏の講演
Message-ID: <20030524.162001.730552856.ken@tydfam.jp>

  独特の略称を使うことにより、そのコミュニティに所属している
事を誇示したいのでしょうが、コミュニティ自体がそれの呼称を否定
しているのだから、意図している事がその通りには機能していない
例として捉えれば良いのでは？ 
  「PostgreSQLを本当に使っている人は、そうは呼ばないんだよ」
って宣伝する必要があるのかも？

  しかし、国のお役所がオープンソースを語ると、やっぱり「支配権」
が日本になければ、云々が入ってしまうのですね。 国の役所という
所の限界を強く感じてしまいました。(オープンソースなんて、支配権
もなければ、国籍もないもので、そのこと自体がオープンソースという
言葉と対立すると考えるのですが、、)

  ３０年近くいわゆる外資で仕事して来て、お役所も昔程外資を差別
しないなー、と最近感じていたのですが、所詮は同じなのかも。いささか
がっかり。経済産業省だからなおさらかも知れませんが。




From nao ＠ dit.co.jp  Sat May 24 16:56:07 2003
From: nao ＠ dit.co.jp (Nao J. Yasuda)
Date: Sat, 24 May 2003 16:56:07 +0900
Subject: [pgsql-jp: 30044] Re: LinuxWorldにおける久米孝氏の講演
In-Reply-To: <20030524.122208.78706067.t-ishii@sra.co.jp>
References: <20030524.122208.78706067.t-ishii@sra.co.jp>
Message-ID: <200305240756.AA06449@sarah.net-g.dit.co.jp>

Tatsuo Ishii さんは書きました:
>> >先日開催されたLinuxWorldで，経済産業省の久米孝氏がPostgreSQLに言及され
>> >たそうですが，どういう話かご存じの方，よかったら教えてください．
>> 
>> http://slashdot.jp/comments.pl?sid=95904&cid=321971

>ここでは久米氏がPostgreSQLを「ポスグレ」と呼んでいることしか分かりませ
>んでした．

久米さんはそれなりに存銃上げているのですが、肝心のLinuxWorldには
参加できずじまいでした。(_ _)
久米さんがどのように言ったかは知らないわけですが、久米さん自身は
経済産業省の課長補佐だけあって、ジェネラリストとして飲み込みが早いのは
確かだと思います。Open Sourceについても感心が高いようで、表面的な
知識は一通りかなり勉強されているようです。
もちろん、実際に使ったことがあるわけではないので、あくまでエキスパート
ではなくジェネラリストとしてですね。いろいろなエキスパートの方々の
意見を集約するジェネラリストとしては優秀だということです。
用語の問題は、久米さんの周りのエキスパートが「ポスグレ」と呼んで
いたのでしょう。それ以外の他意はないように思います。

久米さんに正しいPostgreSQLの知識を吹き込めば、少なくとも経済産業省的な
対応は少しは良くなるかもしれません。ただお役所というところは、
課長以上になると話が急にわからんチンになることが多いので、楽観はできないと
思いますが... ;-p

---やすだ



From aiko_0303 ＠ infoseek.jp  Mon May 26 14:24:39 2003
From: aiko_0303 ＠ infoseek.jp (aiko_0303 ＠ infoseek.jp)
Date: Mon, 26 May 2003 14:24:39 +0900
Subject: [pgsql-jp: 30045] 週単位のデータをもつには？
Message-ID: <20030526142439.aiko_0303@infoseek.jp>

こんにちは。
初めて投稿させていただきます。
よろしくお願いします。


現在、ユーザーIDと週単位でひとつのデータを持つテーブルを作成したいと考えています。

カラム内容
----------------
ユーザーID(主キー)
日付　　　(主キー)
週の情報
更新日時
登録日時
備考


上記の様なテーブル構成を考えていますが、
日付を主キーにしてしまうと、週単位でデータを持つというよりも日付でデータを持つ
感じになってしまい、ちょっと意図しているものと違うかな…という感じなのですが、

このような場合は、

カラム内容
----------------
ユーザーID(主キー)
日付　　　(主キー)
週番号　　(主キー)	※to_char( d,'W')で取得？
週の予定
更新日時
登録日時
備考


の様なテーブル構成にするのが最もスマートでしょうか。
熟練者の皆さんは、どのようになさっているのでしょうか。
日付単位、あるいは、月単位だと
主キーの設定は単純で初心者にも分かりやすいのですが。


PostgreSQLの質問でなくRDBの質問の様な気がしますが、
PostgreSQLを使用しているため、投稿させていただきました。

いろいろサンプルを探してみたのですが、
週単位というものがどうしても見つけられませんでした。

アドバイス頂ければ幸いです。
よろしくお願いします。




------------------------------------------------------------------------
この夏は　周りを出し抜き　ナイスバディ by infoseek
http://shopping.www.infoseek.co.jp/Shtop?pg=sh_diet_if.html&svx=971148 
 





From yutaka ＠ hi-net.zaq.ne.jp  Mon May 26 17:06:21 2003
From: yutaka ＠ hi-net.zaq.ne.jp (Yutaka tanida)
Date: Mon, 26 May 2003 17:06:21 +0900
Subject: [pgsql-jp: 30046] Re: 週単位のデータをもつには？
In-Reply-To: <20030526142439.aiko_0303@infoseek.jp>
References: <20030526142439.aiko_0303@infoseek.jp>
Message-ID: <20030526165826.D1F8.YUTAKA@hi-net.zaq.ne.jp>

谷田です。

On 26 May 2003 14:17:46 +0900
aiko_0303 ＠ infoseek.jp wrote:

> 上記の様なテーブル構成を考えていますが、
> 日付を主キーにしてしまうと、週単位でデータを持つというよりも日付でデータを持つ
> 感じになってしまい、ちょっと意図しているものと違うかな…という感じなのですが、
> 
> このような場合は、
> 
> カラム内容
> ----------------
> ユーザーID(主キー)
> 日付　　　(主キー)
> 週番号　　(主キー)	※to_char( d,'W')で取得？
> 週の予定
> 更新日時
> 登録日時
> 備考
> 
> 
> の様なテーブル構成にするのが最もスマートでしょうか。

上記の３つが主キーと言うことは、('USER1',2003/01/01,1...)と('USER1',2003/01/02,1...)
が別々になるのですか？

primary keyの定義から考えれば、今回設定すべきは

>現在、ユーザーIDと週単位でひとつのデータを持つテーブルを作成したいと
>考えています。

という文章から自ずと明らかだと思います。つまり、

> カラム内容
> ----------------
> ユーザーID(主キー)
> 週番号　　(主キー)

が正解ではないでしょうか。

-- 
Yutaka tanida <yutaka ＠ nonsensecorner.com>
http://www.nonsensecorner.com/



From aiko_0303 ＠ infoseek.jp  Mon May 26 18:23:40 2003
From: aiko_0303 ＠ infoseek.jp (aiko_0303 ＠ infoseek.jp)
Date: Mon, 26 May 2003 18:23:40 +0900
Subject: [pgsql-jp: 30047] Re: 週単位のデータをもつには？
In-Reply-To: <20030526165826.D1F8.YUTAKA@hi-net.zaq.ne.jp>
References: <20030526165826.D1F8.YUTAKA@hi-net.zaq.ne.jp>
Message-ID: <20030526182340.aiko_0303@infoseek.jp>

ご返信ありがとうございます。

>> ユーザーID(主キー)
>> 日付　　　(主キー)
>> 週番号　　(主キー)	※to_char( d,'W')で取得？

>上記の３つが主キーと言うことは、('USER1',2003/01/01,1...)と>>('USER1',2003/01/02,1...)
>が別々になるのですか？
別々にはならないのですが、あえて日付をつけたのは、
週番号とユーザーIDだけだと、
2003年5月の5週目と2004年5月の5週目との区別がつかないと思ったからです。


谷田さんのアドバイスと合わせて、


カラム内容
----------------
ユーザーID(主キー)
週番号　　(主キー)
年月　　　(主キー)

にすれば、良いですね。
簡単なことでした。
頭がごちゃごちゃになってしまっていた様です。

どうもありがとうございました。


------------------------------------------------------------------------
この夏は　周りを出し抜き　ナイスバディ by infoseek
http://shopping.www.infoseek.co.jp/Shtop?pg=sh_diet_if.html&svx=971148 
 





From mashiki ＠ yanah.com  Tue May 27 01:43:12 2003
From: mashiki ＠ yanah.com (Mashiki)
Date: Tue, 27 May 2003 01:43:12 +0900
Subject: [pgsql-jp: 30048] Re: 週単位のデータをもつには？
In-Reply-To: <20030526142439.aiko_0303@infoseek.jp>
References: <20030526142439.aiko_0303@infoseek.jp>
Message-ID: <B1C323A5E5C421mashiki@yanah.com>

　Mashikiです。

　私の感覚では、その年次の週番号など計算で求められるので、
前者の方がすっきりしていて「よりスマート」だと思います。
ただし定義で「日付」という列名を「(対象週)開始日」の意味の
列名に変えたほうがいいとは思います。念を入れるなら、チェック
制約などで特定曜日以外登録できないようにしてもよいと思います。

- ところで「年月」を入れるためのフィールドの型は何にしますか？
- 私でしたら迷わず日付型にします。設計書のコメントには対象年月
- の1日を指定すると添えて。

>現在、ユーザーIDと週単位でひとつのデータを持つテーブルを作成したいと考えて
>います。
>
>カラム内容
>----------------
>ユーザーID(主キー)
>日付　　　(主キー)
>週の情報
>更新日時
>登録日時
>備考
>
>
>上記の様なテーブル構成を考えていますが、
>日付を主キーにしてしまうと、週単位でデータを持つというよりも日付でデータを持つ

>感じになってしまい、ちょっと意図しているものと違うかな…という感じなのですが、

>
>このような場合は、
>
>カラム内容
>----------------
>ユーザーID(主キー)
>日付　　　(主キー)
>週番号　　(主キー)	※to_char( d,'W')で取得？
>週の予定
>更新日時
>登録日時
>備考
>
>
>の様なテーブル構成にするのが最もスマートでしょうか。
>熟練者の皆さんは、どのようになさっているのでしょうか。
>日付単位、あるいは、月単位だと
>主キーの設定は単純で初心者にも分かりやすいのですが。


From ch-999 ＠ beige.plala.or.jp  Tue May 27 09:26:54 2003
From: ch-999 ＠ beige.plala.or.jp (Hisashi Chiba)
Date: Tue, 27 May 2003 09:26:54 +0900
Subject: [pgsql-jp: 30049] 月数の取得（datetime関数の代替）
Message-ID: <003401c323e6$aceadff0$7d334a87@PHOBOS>

PostgreSQL のバージョンを上げようとして、標題の事で躓いています。

従来、PostgreSQL7.2で次のシェルスクリプトで正常に稼働していたのですが、

MM=`psql -d zaimu -A -t -c "select to_char(datetime(to_char(MIN(keiri_date),'9999-99-99')),'MM')
from daily;"`
TM=`psql -d zaimu -A -t -c "select to_char(datetime(to_char(MIN(keiri_date),'9999-99-99')),'MM')
from temp;"`
if [ "$MM" != "$TM" ] ; then

＃ここで、$MM と $TM は文字列として考えています。

これと全く同じスクリプトを、PostgreSQL7.3.2 で実行すると

ERROR:  Function datetime(text) does not exist
        Unable to identify a function that satisfies the given argument types
        You may need to add explicit typecasts

の様なメッセージが表示され、上手く動いていません。

PostgreSQL のバージョンが上がると、サポートされなくなる関数があるのは、
何となく知っていたのですが。

ユーザー会のWebで検索してみましたが、条件指定が悪いのか見つからず、他の方法もな
かなか思いつかないので、良い方法がありましたら教えて頂ければありがたいのですが。




From sirius ＠ jp.fujitsu.com  Tue May 27 09:43:47 2003
From: sirius ＠ jp.fujitsu.com (Takao Kato)
Date: Tue, 27 May 2003 09:43:47 +0900
Subject: [pgsql-jp: 30050] Re: 月数の取得（datetime 関数の代替）
In-Reply-To: <003401c323e6$aceadff0$7d334a87@PHOBOS>
References: <003401c323e6$aceadff0$7d334a87@PHOBOS>
Message-ID: <u38ystqkvw.wl@lespaul.lantc.cs.fujitsu.co.jp>

 加藤＠川崎です。

> PostgreSQL のバージョンを上げようとして、標題の事で躓いています。
> 
> 従来、PostgreSQL7.2で次のシェルスクリプトで正常に稼働していたのですが、
> 
> MM=`psql -d zaimu -A -t -c "select to_char(datetime(to_char(MIN(keiri_date),'9999-99-99')),'MM')
> from daily;"`
> TM=`psql -d zaimu -A -t -c "select to_char(datetime(to_char(MIN(keiri_date),'9999-99-99')),'MM')
> from temp;"`

テーブル構成がないので keiri_date は date(またはtimestamp) と決めつけ
て考えますが、なにも datetime でいったんラップをかけた上で、to_charで
処理しなくても、最初から to_char で処理すれば良いのではないでしょうか?

-- copy&paste --
  % psql -A -t -c "select to_char('2003-05-31'::date,'MM');"
  05
  %
-- copy&paste --

ひょっとして、なにか基本的なことが抜け落ちてたりしますか? > 自分
# それならご指摘願います。 _o_
---------------------------------------------------------------------
加藤＠川崎


From t_suzuki ＠ kenwood-eng.co.jp  Tue May 27 09:55:56 2003
From: t_suzuki ＠ kenwood-eng.co.jp (T.Suzuki)
Date: Tue, 27 May 2003 09:55:56 +0900
Subject: [pgsql-jp: 30051] Re: 月数の取得（datetime 関数の代替）
References: <003401c323e6$aceadff0$7d334a87@PHOBOS>
Message-ID: <000e01c323ea$bb65b470$1e9316ac@sys010>

鈴木＠KEGと申します。

From: "Hisashi Chiba" <ch-999 ＠ beige.plala.or.jp>
> MM=`psql -d zaimu -A -t -c "select
to_char(datetime(to_char(MIN(keiri_date),'9999-99-99')),'MM')
> from daily;"`
> TM=`psql -d zaimu -A -t -c "select
to_char(datetime(to_char(MIN(keiri_date),'9999-99-99')),'MM')
> from temp;"`
> if [ "$MM" != "$TM" ] ; then
>
> ＃ここで、$MM と $TM は文字列として考えています。

datetime型へのキャストが出来ないようです。

取りあえず、以下の様にDate型へ変換すれば実行できます。
（datetimeじゃなくてdateを使用）
#psql -d template0 -A -t -c "select
to_char(date(to_char(20030527,'9999-99-99')),'MM')
#psql -d template0 -A -t -c "select
to_char(to_char(20030527,'9999-99-99')::date,'MM')

datetime型は過去バージョンとの互換性の為に存在していたのですが、
7.3で使えなくなったのでしょうか？

#select typname from pg_type where typname like '%time';
としても、datetimeが見当たらないですね…。
リリースノートを見ても記述はありませんでした。

表やその他SQLで、datetime型を使用しているのでしたら
修正したほうがよさそうですね。
 -----------------------------------------
      鈴木 徹 (SUZUKI Toru)
      KENWOOD ENGINEERING CORPORATION
      E-mail:t_suzuki ＠ kenwood-eng.co.jp
 -----------------------------------------



From ch-999 ＠ beige.plala.or.jp  Tue May 27 10:11:06 2003
From: ch-999 ＠ beige.plala.or.jp (Hisashi Chiba)
Date: Tue, 27 May 2003 10:11:06 +0900
Subject: [pgsql-jp: 30052] Re: 月数の取得（datetime 関数の代替）
References: <003401c323e6$aceadff0$7d334a87@PHOBOS> <000e01c323ea$bb65b470$1e9316ac@sys010>
Message-ID: <005001c323ec$d9cf4780$7d334a87@PHOBOS>

加藤＠川崎さん、鈴木＠ＫＥＧさん、有り難うございます。

鈴木＠ＫＥＧさんから教えて頂いた方法で、対処可能になりました。

> 取りあえず、以下の様にDate型へ変換すれば実行できます。
> （datetimeじゃなくてdateを使用）
> #psql -d template0 -A -t -c "select
> to_char(date(to_char(20030527,'9999-99-99')),'MM')
> #psql -d template0 -A -t -c "select
> to_char(to_char(20030527,'9999-99-99')::date,'MM')

一応、シェルプロンプトから試した結果は次の様になりました。
# psql -d zaimu -A -t -c "select to_char(date(MIN(keiri_date),'MM') from daily;"
04
#

また加藤＠川崎さんの御指摘で、フィールドの型を明示していませんでした。
この keiri_date フィールドは、int8 で定義していたもので、２年程前に訳もわからず
定義していたもので、これが今ごろ足を引っ張っているとは・・・。

ご教授有り難うございました。



From cdb01160 ＠ hkg.odn.ne.jp  Tue May 27 11:09:16 2003
From: cdb01160 ＠ hkg.odn.ne.jp (cdb01160)
Date: Tue, 27 May 2003 11:09:16 +0900
Subject: [pgsql-jp: 30053] to_char(XXXX,'W')と木曜日
Message-ID: <000001c323f4$fa13a650$1401a8c0@compevod300>

(Postgre）SQLを勉強中の佐藤です。

上記関数は、おかしな動作をします。
select to_char('2003-5-1'::date,'W');  答えは１．
select to_char('2003-5-5'::date,'W');  答えは１．
select to_char('2003-5-9'::date,'W');　答えは２．
どうも、「木曜日」区切りになっているようなのですが　?
手元の本では、「月の初日がある週が第1週」と書いてありますけど、、、
「カレンダー」では、木曜区切りにはなっていませんよね。
何処かで、
「最初の木曜日がある週が第１週」みたいな文書も読んだ気がするのですが、

解説していただけないでしょうか?
（分かっていないと、性質の悪いバグになりそうなので、、、、）

以上　佐藤賢治




From pg ＠ matznaga.net  Tue May 27 11:23:52 2003
From: pg ＠ matznaga.net (松永 均)
Date: Tue, 27 May 2003 11:23:52 +0900 (JST)
Subject: [pgsql-jp: 30054] Re: to_char(XXXX,'W')と木曜日
In-Reply-To: <000001c323f4$fa13a650$1401a8c0@compevod300>
References: <000001c323f4$fa13a650$1401a8c0@compevod300>
Message-ID: <20030527.112352.32345776.pg@matznaga.net>

松永です。

> (Postgre）SQLを勉強中の佐藤です。

> 何処かで、
> 「最初の木曜日がある週が第１週」みたいな文書も読んだ気がするのですが、

先日 mhc の ML で話題になっていました。

>> さて，本題ですが，ISO では，
>>
>>  1年の最初の木曜日を含む週を第一週とする．
>>
>> という表現があって，これは分かりやすいですね．

ということでした。

http://www.merlyn.demon.co.uk/weekinfo.htm

という url が紹介されました。

>> 又、Weeknumber の数え方にもいろいろ有ると書いてありました。(特にUS)
>>     # Microsoft も独特だとか

という話も。


From maya ＠ negeta.com  Tue May 27 11:25:32 2003
From: maya ＠ negeta.com (maya)
Date: Tue, 27 May 2003 11:25:32 +0900
Subject: [pgsql-jp: 30055] Re: to_char(XXXX,'W')と木曜日
In-Reply-To: <000001c323f4$fa13a650$1401a8c0@compevod300>
References: <000001c323f4$fa13a650$1401a8c0@compevod300>
Message-ID: <87k7cdnn1f.wl@mail.negeta.com>

mayaです。

> どうも、「木曜日」区切りになっているようなのですが　?
> 手元の本では、「月の初日がある週が第1週」と書いてありますけど、、、
> 「カレンダー」では、木曜区切りにはなっていませんよね。
○/1〜○/7  -> 第一週
○/8〜○/14 -> 第二週
ということだと思います。2003/5/1は木曜日だから切り替わる
のが木曜日になるのでは？

# もしかして、5/1-3は1を、5/4-10は2を返してほしいとか？


| maya <maya ＠ negeta.com> |


From hideyuki.nakamine ＠ adst.keio.ac.jp  Tue May 27 11:26:17 2003
From: hideyuki.nakamine ＠ adst.keio.ac.jp (Hideyuki Nakamine)
Date: Tue, 27 May 2003 11:26:17 +0900
Subject: [pgsql-jp: 30056] Accessからの日付条件指定について
Message-ID: <3ED2CCC9.707F6D9E@adst.keio.ac.jp>

はじめまして、那賀と申します。

先月初めてPostgresを導入し運用を行っていますが、従来から利用してきた
Access2000を引き続き利用するためにODBCドライバーを入れリンク設定まで
は無事完了することができました。また、追加・削除・更新等も何とかやり
くりしていますが、どうしても上手くいかない点があります。

それは、日付をクエリーで条件指定しようとすると発生します。具体的には、
SQL文にすると下記のような単純な指定でエラーが発生します。

 SELECT aa.yd 
 FROM aa 
 WHERE aa.yd = #2003/10/10#

エラーメッセージは、
「ODBC--呼び出しが失敗しました。
　ERROR:Unable to identify an operator '=' for types 'timestamp
        without time zone' and 'date' You will have to retype this
        query using an explicit cast」

というものです。AccessからODBC経由での日付に関する条件指定では何か特
別な記述等が必要なのでしょうか？

よろしくお願いいたします。


From yiwakiri ＠ st.rim.or.jp  Tue May 27 11:37:38 2003
From: yiwakiri ＠ st.rim.or.jp (Youichi Iwakiri)
Date: Tue, 27 May 2003 11:37:38 +0900
Subject: [pgsql-jp: 30057] Re: to_char(XXXX,'W')と木曜日
In-Reply-To: <000001c323f4$fa13a650$1401a8c0@compevod300>
References: <000001c323f4$fa13a650$1401a8c0@compevod300>
Message-ID: <200305270237.LAA13966@mail6.rim.or.jp>

いわきりです

cdb01160 wrote in <000001c323f4$fa13a650$1401a8c0 ＠ compevod300> :
>(Postgre）SQLを勉強中の佐藤です。
>
>上記関数は、おかしな動作をします。
>select to_char('2003-5-1'::date,'W');  答えは１．
>select to_char('2003-5-5'::date,'W');  答えは１．
>select to_char('2003-5-9'::date,'W');　答えは２．
>どうも、「木曜日」区切りになっているようなのですが　?
>手元の本では、「月の初日がある週が第1週」と書いてありますけど、、、
>「カレンダー」では、木曜区切りにはなっていませんよね。
>何処かで、
>「最初の木曜日がある週が第１週」みたいな文書も読んだ気がするのですが、

ISO 8601形式の週表記じゃないですか。

time-interval of seven days, starting on a Monday and identified by its ordinal
 number within a calendar year.

一週間は月曜から日曜まで。

the first calendar week of a year is the one that includes the first Thursday of that year
 and  the last calendar week of a calendar year is the week 
immediately preceding the first calendar week of the next year.

年最初の週は、その年の最初の木曜日を含むこと。

to_char()で、
'W'を使った場合は単純に7日区切りで当月の週を、
'WW'を使った場合は　...
'IW'を使った場合は　...

http://osb.sra.co.jp/PostgreSQL/Manual/PostgreSQL-7.1-ja/functions-formatting.html

見れば、よろしいかと。

-- 
Youichi Iwakiri



From cdb01160 ＠ hkg.odn.ne.jp  Tue May 27 11:56:46 2003
From: cdb01160 ＠ hkg.odn.ne.jp (cdb01160)
Date: Tue, 27 May 2003 11:56:46 +0900
Subject: [pgsql-jp: 30058] Re: to_char(XXXX,'W')と木曜日
In-Reply-To: <20030527.112352.32345776.pg@matznaga.net>
Message-ID: <000001c323fb$9fdab5a0$1401a8c0@compevod300>

佐藤です。

松永さん、maya　さんありがとうございます。
結局　この動作が、「仕様」なんですね。

で、最終ユーザーとのインターフェースは「自分で、書け」と言う事なんだ。

この　URL　は、貴重ですね。Delphi　のプログラムもあるようなので、
後で、じっくり読まさせていただきます。

ありがとうございました。

以上　佐藤賢治




From aiko_0303 ＠ infoseek.jp  Tue May 27 14:22:26 2003
From: aiko_0303 ＠ infoseek.jp (aiko_0303 ＠ infoseek.jp)
Date: Tue, 27 May 2003 14:22:26 +0900
Subject: [pgsql-jp: 30059] Re: 週単位のデータをもつには？
In-Reply-To: <B1C323A5E5C421mashiki@yanah.com>
References: <B1C323A5E5C421mashiki@yanah.com>
Message-ID: <20030527142226.aiko_0303@infoseek.jp>

こんにちは。お世話になります。


> 　私の感覚では、その年次の週番号など計算で求められるので、
> 前者の方がすっきりしていて「よりスマート」だと思います。
> ただし定義で「日付」という列名を「(対象週)開始日」の意味の
> 列名に変えたほうがいいとは思います。念を入れるなら、チェック
> 制約などで特定曜日以外登録できないようにしてもよいと思います。


カラム内容
----------------
ユーザーID　　(主キー)
(対象週)開始日(主キー)
週の情報
更新日時
登録日時
備考

とう構成ですね。

INSERTする日付の週の開始日を求めて、
それをキーにテーブル作成という感じでしょうか。

確かにそれが一番スマートな気がします。


アドバイスいただきありがとうございました！




------------------------------------------------------------------------
この夏は　周りを出し抜き　ナイスバディ by infoseek
http://shopping.www.infoseek.co.jp/Shtop?pg=sh_diet_if.html&svx=971148 
 





From iwase-h ＠ mxy.nes.nec.co.jp  Tue May 27 14:48:04 2003
From: iwase-h ＠ mxy.nes.nec.co.jp (岩瀬　肇)
Date: Tue, 27 May 2003 14:48:04 +0900
Subject: [pgsql-jp: 30060] Re: Accessからの日付条件指定について
In-Reply-To: <3ED2CCC9.707F6D9E@adst.keio.ac.jp>
References: <3ED2CCC9.707F6D9E@adst.keio.ac.jp>
Message-ID: <20030527144520.99CD.IWASE-H@mxy.nes.nec.co.jp>

岩瀬と申します。

テスト環境がないので、憶測ですが日付は文字列として扱われると思いますので、
日付部分をシングルクォーテーション等で囲ってみてはいかがでしょうか？
具体的には
SELECT aa.yd FROM aa WHERE aa.yd='2003/10/10'
という具合です。


> はじめまして、那賀と申します。
> 
> 先月初めてPostgresを導入し運用を行っていますが、従来から利用してきた
> Access2000を引き続き利用するためにODBCドライバーを入れリンク設定まで
> は無事完了することができました。また、追加・削除・更新等も何とかやり
> くりしていますが、どうしても上手くいかない点があります。
> 
> それは、日付をクエリーで条件指定しようとすると発生します。具体的には、
> SQL文にすると下記のような単純な指定でエラーが発生します。
> 
>  SELECT aa.yd 
>  FROM aa 
>  WHERE aa.yd = #2003/10/10#
> 
> エラーメッセージは、
> 「ODBC--呼び出しが失敗しました。
> 　ERROR:Unable to identify an operator '=' for types 'timestamp
>         without time zone' and 'date' You will have to retype this
>         query using an explicit cast」
> 
> というものです。AccessからODBC経由での日付に関する条件指定では何か特
> 別な記述等が必要なのでしょうか？
> 
> よろしくお願いいたします。

-- 
岩瀬　肇 <iwase-h ＠ mxy.nes.nec.co.jp>



From hideyuki.nakamine ＠ adst.keio.ac.jp  Tue May 27 15:10:48 2003
From: hideyuki.nakamine ＠ adst.keio.ac.jp (Hideyuki Nakamine)
Date: Tue, 27 May 2003 15:10:48 +0900
Subject: [pgsql-jp: 30061] Re: Accessからの日付条件指定について
References: <3ED2CCC9.707F6D9E@adst.keio.ac.jp> <20030527144520.99CD.IWASE-H@mxy.nes.nec.co.jp>
Message-ID: <3ED30168.463A1631@adst.keio.ac.jp>

那賀です。

岩瀬さんありがとうございます。

早速やってみましたが、
　「抽出条件でデータ型が一致しません。」
ということでエラーが出てしまいます。ダブルクォーテーションでも同様
です。ということは、やはり日付として扱われてはいるのでしょうか。

よろしくお願いいたします。

岩瀬　肇 wrote:

> テスト環境がないので、憶測ですが日付は文字列として扱われると思いますので、
> 日付部分をシングルクォーテーション等で囲ってみてはいかがでしょうか？
> 具体的には
> SELECT aa.yd FROM aa WHERE aa.yd='2003/10/10'
> という具合です。
> 

> > それは、日付をクエリーで条件指定しようとすると発生します。具体的には、
> > SQL文にすると下記のような単純な指定でエラーが発生します。
> >
> >  SELECT aa.yd
> >  FROM aa
> >  WHERE aa.yd = #2003/10/10#
> >
> > エラーメッセージは、
> > 「ODBC--呼び出しが失敗しました。
> > 　ERROR:Unable to identify an operator '=' for types 'timestamp
> >         without time zone' and 'date' You will have to retype this
> >         query using an explicit cast」
> >
> > というものです。AccessからODBC経由での日付に関する条件指定では何か特
> > 別な記述等が必要なのでしょうか？


From m-nakagawa-n ＠ na.jsystem.co.jp  Tue May 27 15:21:03 2003
From: m-nakagawa-n ＠ na.jsystem.co.jp (SFC Nakagawa)
Date: Tue, 27 May 2003 15:21:03 +0900
Subject: [pgsql-jp: 30062] はじめまして
Message-ID: <000501c32418$29db2a70$641e0aaa@1stjeg>

みなさん、はじめまして
新しくこのＭＬに参加した中川という者です。

質問があるのですが

ＩＤＳ（snort)マシンのログの管理にpostgresqlを使いたいのですが、DBのアクセス
権を他のユーザーに
つけようとすると、,元のDBのクラスがないと言うようなエラーを吐きます。

やっていることはsnortlogと言うDBユーザーのsnortlogと言うDBを作りました。
WEBからのアクセスがあるのでGRANTを使ってnobodyに参照権を与えるとエラになりま
す。

以下のような状況です。
[root ＠ koba init.d]# su snortlog
[snortlog ＠ koba init.d]$ psql
Welcome to psql, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help on internal slash commands
       \g or terminate with semicolon to execute query
       \q to quit

snortlog=> GRANT SELECT ON snortlog TO nobody;
ERROR:  pg_ownercheck: class "snortlog" not found
snortlog=>

ちなみにpsqlで\dを打つとちゃんとｌｉｓｔを表示します。
環境はredhat8.0
　　　　postgresqlは7.2のrpm版です。

他のＩＤＳ管理者のＨＰ等参照しましたが特に触れられていないので、特殊なケース
とは思いますが
まったく打つ手が見つかりません。
何とか知恵をお貸しください。

/===========================================================
101System/NASigGp/JGSDF
SFC M . Nakagawa

m-nakagawa-n ＠ na.jsystem.co.jp
============================================================/



From gontakun ＠ fish.co.jp  Tue May 27 15:31:39 2003
From: gontakun ＠ fish.co.jp (Chie.M)
Date: Tue, 27 May 2003 15:31:39 +0900
Subject: [pgsql-jp: 30063] Re: Accessからの日付条件指定について
In-Reply-To: <3ED30168.463A1631@adst.keio.ac.jp>
References: <20030527144520.99CD.IWASE-H@mxy.nes.nec.co.jp> <3ED30168.463A1631@adst.keio.ac.jp>
Message-ID: <20030527153006.AC8D.GONTAKUN@fish.co.jp>

Chie.Mです。

> 早速やってみましたが、
> 　「抽出条件でデータ型が一致しません。」
> ということでエラーが出てしまいます。ダブルクォーテーションでも同様
> です。ということは、やはり日付として扱われてはいるのでしょうか。

私の場合は、Accessでの日付の書式を
PostgreSQL用の日付型に変更して''で囲っています。
YYYY-MM-DDの形です。

これでいかがでしょうか？
----------------------------
Chie.M <gontakun ＠ fish.co.jp>



From iwase-h ＠ mxy.nes.nec.co.jp  Tue May 27 15:35:35 2003
From: iwase-h ＠ mxy.nes.nec.co.jp (岩瀬　肇)
Date: Tue, 27 May 2003 15:35:35 +0900
Subject: [pgsql-jp: 30064] Re: Accessからの日付条件指定について
In-Reply-To: <3ED30168.463A1631@adst.keio.ac.jp>
References: <20030527144520.99CD.IWASE-H@mxy.nes.nec.co.jp> <3ED30168.463A1631@adst.keio.ac.jp>
Message-ID: <20030527152941.99CF.IWASE-H@mxy.nes.nec.co.jp>

岩瀬です。

えっと…エラーが
「抽出条件でデータ型が一致しません。」
となったということは、エラー内容は変わったんでしょうか？

Date型の形式をYYYY/MM/DDからYYYY-MM-DDへ変えてみてはいかがでしょうか？
また、ODBCドライバーは最新版をご使用されていますでしょうか？


> 那賀です。
> 
> 岩瀬さんありがとうございます。
> 
> 早速やってみましたが、
> 　「抽出条件でデータ型が一致しません。」
> ということでエラーが出てしまいます。ダブルクォーテーションでも同様
> です。ということは、やはり日付として扱われてはいるのでしょうか。
> 
> よろしくお願いいたします。
> 
> 岩瀬　肇 wrote:
> 
> > テスト環境がないので、憶測ですが日付は文字列として扱われると思いますので、
> > 日付部分をシングルクォーテーション等で囲ってみてはいかがでしょうか？
> > 具体的には
> > SELECT aa.yd FROM aa WHERE aa.yd='2003/10/10'
> > という具合です。
> > 
> 
> > > それは、日付をクエリーで条件指定しようとすると発生します。具体的には、
> > > SQL文にすると下記のような単純な指定でエラーが発生します。
> > >
> > >  SELECT aa.yd
> > >  FROM aa
> > >  WHERE aa.yd = #2003/10/10#
> > >
> > > エラーメッセージは、
> > > 「ODBC--呼び出しが失敗しました。
> > > 　ERROR:Unable to identify an operator '=' for types 'timestamp
> > >         without time zone' and 'date' You will have to retype this
> > >         query using an explicit cast」
> > >
> > > というものです。AccessからODBC経由での日付に関する条件指定では何か特
> > > 別な記述等が必要なのでしょうか？

-- 
岩瀬　肇 <iwase-h ＠ mxy.nes.nec.co.jp>



From t_suzuki ＠ kenwood-eng.co.jp  Tue May 27 15:38:26 2003
From: t_suzuki ＠ kenwood-eng.co.jp (T.Suzuki)
Date: Tue, 27 May 2003 15:38:26 +0900
Subject: [pgsql-jp: 30065] Re: Accessからの日付条件指定について
References: <3ED2CCC9.707F6D9E@adst.keio.ac.jp>
Message-ID: <004e01c3241a$93ee3f40$1e9316ac@sys010>

鈴木＠KEGと申します。

From: "Hideyuki Nakamine" <hideyuki.nakamine ＠ adst.keio.ac.jp>
>  SELECT aa.yd
>  FROM aa
>  WHERE aa.yd = #2003/10/10#

> 「ODBC--呼び出しが失敗しました。
> 　ERROR:Unable to identify an operator '=' for types 'timestamp
>         without time zone' and 'date' You will have to retype this
>         query using an explicit cast」

エラーメッセージを見る限りでは、SQLの比較で失敗している様です。
#簡単ですし、訳してみましょう

テーブル構成は記載されてませんが、"aa.yd"は、
PostgreSQLのtimestamp型のようですね。

このSQLが、Access2000で実行したのかPostgreSQLで実行したのか
解らないので、Access側で実行したと仮定しました。
'2003/10/10'の文字列はdate型に暗黙にCASTされているので、
"aa.yd"を明示的にCASTします。

#select aa.yd from aa
#where aa.yd::date = '2003/10/10';

これでどうでしょうか？
 -----------------------------------------
      鈴木 徹 (SUZUKI Toru)
      KENWOOD ENGINEERING CORPORATION
      E-mail:t_suzuki ＠ kenwood-eng.co.jp
 -----------------------------------------

----- Original Message -----
From: "Hideyuki Nakamine" <hideyuki.nakamine ＠ adst.keio.ac.jp>
To: <pgsql-jp ＠ ml.postgresql.jp>
Sent: Tuesday, May 27, 2003 11:26 AM
Subject: [pgsql-jp: 30056] Accessからの日付条件指定について


> はじめまして、那賀と申します。
>
> 先月初めてPostgresを導入し運用を行っていますが、従来から利用してきた
> Access2000を引き続き利用するためにODBCドライバーを入れリンク設定まで
> は無事完了することができました。また、追加・削除・更新等も何とかやり
> くりしていますが、どうしても上手くいかない点があります。
>
> それは、日付をクエリーで条件指定しようとすると発生します。具体的には、
> SQL文にすると下記のような単純な指定でエラーが発生します。
>
>  SELECT aa.yd
>  FROM aa
>  WHERE aa.yd = #2003/10/10#
>
> エラーメッセージは、
> 「ODBC--呼び出しが失敗しました。
> 　ERROR:Unable to identify an operator '=' for types 'timestamp
>         without time zone' and 'date' You will have to retype this
>         query using an explicit cast」
>
> というものです。AccessからODBC経由での日付に関する条件指定では何か特
> 別な記述等が必要なのでしょうか？
>
> よろしくお願いいたします。
>



From hideyuki.nakamine ＠ adst.keio.ac.jp  Tue May 27 16:11:06 2003
From: hideyuki.nakamine ＠ adst.keio.ac.jp (Hideyuki Nakamine)
Date: Tue, 27 May 2003 16:11:06 +0900
Subject: [pgsql-jp: 30066] Re: Accessからの日付条件指定について
References: <3ED2CCC9.707F6D9E@adst.keio.ac.jp> <004e01c3241a$93ee3f40$1e9316ac@sys010>
Message-ID: <3ED30F8A.2C90D2DE@adst.keio.ac.jp>

那賀です。

Chie.Mさん、岩瀬さん、鈴木＠KEGさんどうもありがとうございます。

それぞれ示唆いただきました方法を試してみました。

まず、Chie.Mさんと岩瀬さんから教えていただきました
　「Date型の形式をYYYY/MM/DDからYYYY-MM-DDに変える」
という方法を試しましたが、「抽出条件でデータ型が一致しません。」
というエラーメッセージは変わりません。また、岩瀬さんから示唆い
ただきましたODBCドライバーのバージョンですが、7.02.00.05となって
います。

鈴木＠KEGさんから教えていただきました
「#select aa.yd from aa
　#where aa.yd::date = '2003/10/10';」
ですが、「構文エラー 演算子がありません。」というエラーが出てし
まいます。「::」の部分でひっかかっているようです。また、このまま
日付部分をYYYY-MM-DDに変える等も試しましたが同様のエラーです。

ちなみに、実行はAccess2000のクエリー画面で行っていますので上の2
種類のエラーメッセージは全てAccess側の実行でのものだと思われます。
逆に、当初出た英文の方はPostgres側まで行き着いてからのものではな
いかと思うのですが...。

また、説明が不足していた部分がありましたが、aa.ydのydはtimestamp
型になっております。

よろしくお願いいたします。


> > それは、日付をクエリーで条件指定しようとすると発生します。具体的には、
> > SQL文にすると下記のような単純な指定でエラーが発生します。
> >
> >  SELECT aa.yd
> >  FROM aa
> >  WHERE aa.yd = #2003/10/10#
> >
> > エラーメッセージは、
> > 「ODBC--呼び出しが失敗しました。
> > 　ERROR:Unable to identify an operator '=' for types 'timestamp
> >         without time zone' and 'date' You will have to retype this
> >         query using an explicit cast」
> >
> > というものです。AccessからODBC経由での日付に関する条件指定では何か特
> > 別な記述等が必要なのでしょうか？
> >
> > よろしくお願いいたします。
> >


From Haruo.Yamamoto ＠ konica.co.jp  Tue May 27 16:38:46 2003
From: Haruo.Yamamoto ＠ konica.co.jp (山本晴夫)
Date: Tue, 27 May 2003 16:38:46 +0900
Subject: [pgsql-jp: 30067] Re: Accessからの日付条件指定について
In-Reply-To: <3ED30F8A.2C90D2DE@adst.keio.ac.jp>
References: <3ED30F8A.2C90D2DE@adst.keio.ac.jp>
Message-ID: <200305270738.AA00292@hat185.hdq.konica.co.jp>

こんにちは。
コニカビジネスエキスパートの山本と申します。

Hideyuki Nakamine さんは書きました:
>ただきましたODBCドライバーのバージョンですが、7.02.00.05となって
>います。

ODBCドライバー 7.03.01.00 (2003/05/15版)を
使ってますが、同様のクエリーでもうまく動き
ます。ドライバーを更新してみたら如何でしょう。

---------------- 以下テスト条件 -------------------
WindowsXP + MS-Access 2002 + ODBCドライバー 
7.03.01.00

PostgreSQL 7.3.2    timestamp (without timezone)
PostgreSQL 7.2      timestamp (with timezone)

抽出条件の表記は 
  WHERE timestampFieldName = #05/27/2003#
みたいになります。

#yyyy/mm/dd# と書いてもクエリー保存時にMS-Accessが
勝手に #mm/dd/yyyy# 形式に変換してしまう様です。
-----------------------------------------------------

--------------------------------------------------
  コニカビジネスエキスパート株式会社　 山本晴夫
       Haruo.Yamamoto ＠ konica.co.jp
--------------------------------------------------


From gontakun ＠ fish.co.jp  Tue May 27 16:50:48 2003
From: gontakun ＠ fish.co.jp (Chie.M)
Date: Tue, 27 May 2003 16:50:48 +0900
Subject: [pgsql-jp: 30068] Re: Accessからの日付条件指定について
In-Reply-To: <3ED30F8A.2C90D2DE@adst.keio.ac.jp>
References: <004e01c3241a$93ee3f40$1e9316ac@sys010> <3ED30F8A.2C90D2DE@adst.keio.ac.jp>
Message-ID: <20030527164428.AC9F.GONTAKUN@fish.co.jp>

Chie.Mです。

> ちなみに、実行はAccess2000のクエリー画面で行っていますので上の2
> 種類のエラーメッセージは全てAccess側の実行でのものだと思われます。
> 逆に、当初出た英文の方はPostgres側まで行き着いてからのものではな
> いかと思うのですが...。

おっしゃるとおりです。

下記2点のエラーはパススルークエリにせずに、普通のSQLで実行した時に
発生すると思われます。

> 「抽出条件でデータ型が一致しません。」
・・・
>「構文エラー 演算子がありません。」というエラーが出てし
> まいます。「::」の部分でひっかかっているようです。

再度、パススルークエリのSQLで指定してみてください。

私も試してみましたが、timestamp型であるなら

鈴木＠KEGさんの
　select aa.yd from aa where aa.yd::date = '2003/10/10';

の形式でパススルークエリで、問題なく実行できました。

ちなみに、私のODBCは
　PostgreSQL ODBC Driver 07.01.0006 日本語版
なので古いようなんですが、実行できています。

ただ、このバージョンのせいかわかりませんが、日付は#で囲んでも
エラーになります。

日付の形式をYYYY-MM-DDとし、''で囲む事と正しく実行できます。

ご参考まで。
----------------------------
Chie.M <gontakun ＠ fish.co.jp>



From linux ＠ nao-star.com  Tue May 27 17:00:10 2003
From: linux ＠ nao-star.com (NAO★)
Date: Tue, 27 May 2003 17:00:10 +0900
Subject: [pgsql-jp: 30069] Re: はじめまして
In-Reply-To: <000501c32418$29db2a70$641e0aaa@1stjeg>
References: <000501c32418$29db2a70$641e0aaa@1stjeg>
Message-ID: <20030527165024.E830.LINUX@nao-star.com>

こんにちは。 ＮＡＯ★といいます。

> やっていることはsnortlogと言うDBユーザーのsnortlogと言うDBを作りました。
> WEBからのアクセスがあるのでGRANTを使ってnobodyに参照権を与えるとエラになりま
> す。

GRANT の使い方が違っています。
マニュアルには、

GRANT privilege [, ...] ON object [, ...]
    TO { PUBLIC | GROUP group | username }

[中略]

object
　アクセス権限を与えるオブジェクトの名前です。
　使用可能な オブジェクトは以下のものです。 
　　・テーブル (table) 
　　・ビュー (view) 
　　・シーケンス (sequence) 

とあり、DB自体を設定することはできないようです。

-- 
NAO★<nao ＠ nao-star.com>



From hideyuki.nakamine ＠ adst.keio.ac.jp  Tue May 27 17:11:48 2003
From: hideyuki.nakamine ＠ adst.keio.ac.jp (Hideyuki Nakamine)
Date: Tue, 27 May 2003 17:11:48 +0900
Subject: [pgsql-jp: 30070] Re: Accessからの日付条件指定について
References: <004e01c3241a$93ee3f40$1e9316ac@sys010> <3ED30F8A.2C90D2DE@adst.keio.ac.jp> <20030527164428.AC9F.GONTAKUN@fish.co.jp>
Message-ID: <3ED31DC4.9CFD7D95@adst.keio.ac.jp>

那賀です。

Chie.Mさん、山本さん どうもありがとうございます。

パススルークエリを指定して実行したところ無事に動作いたしました。
鈴木＠KEGさんに示していただいたSQLで問題なく動作しました。
この後ODBCドライバーの方も最新版に更新しようと思います。

パススルークエリについては今までほとんど使ったことがなかったため
に今回の件に当たっての使用を思いつきませんでした。普通のクエリー
画面を使用しておりました。

お陰様で無事に解決いたしました。


お忙しい中、返信いただきました皆様どうもありがとうございました。


From junai ＠ jmail.plala.or.jp  Tue May 27 19:27:17 2003
From: junai ＠ jmail.plala.or.jp (junai)
Date: Tue, 27 May 2003 19:27:17 +0900
Subject: [pgsql-jp: 30071]  Re: Accessからの日付条件指定について
References: <004e01c3241a$93ee3f40$1e9316ac@sys010> <3ED30F8A.2C90D2DE@adst.keio.ac.jp> <20030527164428.AC9F.GONTAKUN@fish.co.jp> <3ED31DC4.9CFD7D95@adst.keio.ac.jp>
Message-ID: <3ED33D85.5B071EE9@jmail.plala.or.jp>

はじめまして　呉といいます。

普通のクエリー画面でできなくてパススルーでできているということは
Access側に原因があって、多分Jetエンジンをアップデートすれば
解決されると思うのですが。いかがでしょう。

http://support.microsoft.com/default.aspx?scid=kb;ja;282010#3



From gontakun ＠ fish.co.jp  Tue May 27 20:16:43 2003
From: gontakun ＠ fish.co.jp (Chie.M)
Date: Tue, 27 May 2003 20:16:43 +0900
Subject: [pgsql-jp: 30072] Re: Accessからの日付条件指定について
In-Reply-To: <3ED33D85.5B071EE9@jmail.plala.or.jp>
References: <3ED31DC4.9CFD7D95@adst.keio.ac.jp> <3ED33D85.5B071EE9@jmail.plala.or.jp>
Message-ID: <20030527201504.7DA1.GONTAKUN@fish.co.jp>

Chie.Mです。

> 普通のクエリー画面でできなくてパススルーでできているということは
> Access側に原因があって、多分Jetエンジンをアップデートすれば
> 解決されると思うのですが。いかがでしょう。

えーっと、それは聞いた事がないのですが(^^ゞ
アップデートするとODBCを介さずに、PostgreSQLにアクセスできるように
なるということでしょうか？

どこかに、それについて書かれているものとかありますか？
# 話がずれてましてスミマセン。
----------------------------
Chie.M <gontakun ＠ fish.co.jp>



From junai ＠ jmail.plala.or.jp  Wed May 28 01:02:46 2003
From: junai ＠ jmail.plala.or.jp (ＧＯ)
Date: Wed, 28 May 2003 01:02:46 +0900
Subject: [pgsql-jp: 30073]  Re: Accessからの日付条件指定について
References: <3ED31DC4.9CFD7D95@adst.keio.ac.jp> <3ED33D85.5B071EE9@jmail.plala.or.jp> <20030527201504.7DA1.GONTAKUN@fish.co.jp>
Message-ID: <3ED38C26.C3C14F42@jmail.plala.or.jp>

呉です。
#postgresと離れてしまいますね。

> 
> Chie.Mです。
> 
> > 普通のクエリー画面でできなくてパススルーでできているということは
> > Access側に原因があって、多分Jetエンジンをアップデートすれば
> > 解決されると思うのですが。いかがでしょう。
> 
> えーっと、それは聞いた事がないのですが(^^ゞ
> アップデートするとODBCを介さずに、PostgreSQLにアクセスできるように
> なるということでしょうか？

いえ。ODBCドライバを介さずにPostgreSQLにアクセスはできないはず。
要はODBCドライバに渡す前に問題があるのではないかと思ったわけです。
それはJetエンジンの解析を受けるかどうかによってエラーがでたり
でなかったりしているからです。
パススルーは名前のごとくJetを通過（パススルー）します。
Jetはパススルークエリーはいじらずに素通りさせます。
しかし通常のAccess クエリーはJetエンジンによって解析、コンパイル
最適化がされます。（たしか？）
そして古いバージョンのJetは以前より日付型の変換でバグがあったような
気がしました。
このへんでJetをアップデートされることをおすすめしました。
まったくの空振りかもしれませんが。

ちなみに自分の環境ではパススルークエリーでない通常のクエリー画面で
日付条件の選択は可能です。
エラーはでません。
PostgreSQL ODBC Driver 07.01.0006 日本語版
Access2000
昨年末にJetをアップデートしました。

あとパススルークエリーではデータの更新はできませんので通常のクエリーの
代わりとしてはつかえないと思います。

> どこかに、それについて書かれているものとかありますか？
これというものはないですね。



From Inoue ＠ tpf.co.jp  Wed May 28 09:14:45 2003
From: Inoue ＠ tpf.co.jp (Hiroshi Inoue)
Date: Wed, 28 May 2003 09:14:45 +0900
Subject: [pgsql-jp: 30074] Re: Accessからの日付条件指定について
References: <004e01c3241a$93ee3f40$1e9316ac@sys010> <3ED30F8A.2C90D2DE@adst.keio.ac.jp> <20030527164428.AC9F.GONTAKUN@fish.co.jp> <3ED31DC4.9CFD7D95@adst.keio.ac.jp>
Message-ID: <3ED3FF75.270ED586@tpf.co.jp>

井上です。

> 那賀です。
> 
> Chie.Mさん、山本さん どうもありがとうございます。
> 
> パススルークエリを指定して実行したところ無事に動作いたしました。
> 鈴木＠KEGさんに示していただいたSQLで問題なく動作しました。
> この後ODBCドライバーの方も最新版に更新しようと思います。

サーバーのバージョンが書かれていなかったのですが、７．２
ではないでしょうか？　７．２のバグだと思いますが、dateと
timestamp without time zoneの暗黙の比較を行なってくれない
ため、那賀さんが投稿されたようなエラーが発生します。
その現象に対応したドライバ(7.3.0105)を
　http://www.geocities.jp/inocchichichi/psqlodbc/indexj.html
にアップしておきました。

なお、オフィシャル版は7.3.0100よりODBC3.0版が標準となりま
した。ご注意ください。ODBC2.50版はPostgreSQL Legacyという
ドライバをご使用ください。

Hiroshi Inoue
	http://www.geocities.jp/inocchichichi/psqlodbc/


From hideyuki.nakamine ＠ adst.keio.ac.jp  Wed May 28 09:40:00 2003
From: hideyuki.nakamine ＠ adst.keio.ac.jp (Hideyuki Nakamine)
Date: Wed, 28 May 2003 09:40:00 +0900
Subject: [pgsql-jp: 30075] Re: Accessからの日付条件指定について
References: <004e01c3241a$93ee3f40$1e9316ac@sys010> <3ED30F8A.2C90D2DE@adst.keio.ac.jp> <20030527164428.AC9F.GONTAKUN@fish.co.jp> <3ED31DC4.9CFD7D95@adst.keio.ac.jp> <3ED3FF75.270ED586@tpf.co.jp>
Message-ID: <3ED40560.9D2C32B5@adst.keio.ac.jp>

那賀です。

おはようございます。

その後色々と皆さんから引き続き教えていただきどうもありがとうございます。

いただいたメールで複数の環境で試してみました。

　1.Jetのアップデート & ODBC 7.3.0105のアップデート
　　　普通のクエリー画面で正常に動作しました。

　2.Jetのアップデートのみ
　　　私たちの環境ではアップデート前のエラーと変化がありませんでした。

　3.ODBC 7.3.0105のアップデートのみ
　　　普通のクエリー画面で正常に動作しました。

ということで、私たちの環境では、「ODBC 7.3.0105のアップデート」が決め手
となりそうです。

本来のpostgresのやりとりからは少し離れてしまうことになり申し訳ありませ
んでした。やりとりの最初に私の環境をもっと正確に記述しておけばよかった
と反省しております。

 PostgreSQL 7.2.4
 ODBC(旧環境) 07.02.0005

この2日間のやりとりでは上記問題以外にも色々と勉強になりました。

皆さんお忙しい中、お手数をおかけしましてどうもありがとうございました。

Hiroshi Inoue wrote:

> サーバーのバージョンが書かれていなかったのですが、７．２
> ではないでしょうか？　７．２のバグだと思いますが、dateと
> timestamp without time zoneの暗黙の比較を行なってくれない
> ため、那賀さんが投稿されたようなエラーが発生します。
> その現象に対応したドライバ(7.3.0105)を
> 　http://www.geocities.jp/inocchichichi/psqlodbc/indexj.html
> にアップしておきました。


From gontakun ＠ fish.co.jp  Wed May 28 09:42:53 2003
From: gontakun ＠ fish.co.jp (Chie.M)
Date: Wed, 28 May 2003 09:42:53 +0900
Subject: [pgsql-jp: 30076] Re: Accessからの日付条件指定について
In-Reply-To: <3ED38C26.C3C14F42@jmail.plala.or.jp>
References: <20030527201504.7DA1.GONTAKUN@fish.co.jp> <3ED38C26.C3C14F42@jmail.plala.or.jp>
Message-ID: <20030528093743.E907.GONTAKUN@fish.co.jp>

Chie.Mです。
呉さんありがとうございます。

> いえ。ODBCドライバを介さずにPostgreSQLにアクセスはできないはず。

やはり、そうですよね。

> そして古いバージョンのJetは以前より日付型の変換でバグがあったような
> 気がしました。
> このへんでJetをアップデートされることをおすすめしました。
> まったくの空振りかもしれませんが。

なるほど。
私の方は、機能でなく使い方が違っているのではと
考えたのでこのような質問になりました。失礼いたしました。

> ちなみに自分の環境ではパススルークエリーでない通常のクエリー画面で
> 日付条件の選択は可能です。

PostgreSQL独自のSQL文である場合はエラーになります。
Accessで使用できるSQLであれば日付でも条件の指定はもちろんできます。

> あとパススルークエリーではデータの更新はできませんので通常のクエリーの
> 代わりとしてはつかえないと思います。

ADO使ってれば特に問題ないかと。

話がむちゃくちゃずれてしまったのでこの辺で(^^ゞ
----------------------------
Chie.M <gontakun ＠ fish.co.jp>



From s.masugata ＠ digicom.dnp.co.jp  Wed May 28 11:42:00 2003
From: s.masugata ＠ digicom.dnp.co.jp (Seiji Masugata)
Date: Wed, 28 May 2003 11:42:00 +0900
Subject: [pgsql-jp: 30077] PostgreSQL7.3.3 Released!!
Message-ID: <200305280242.LAA29724@azusa.digicom.dnp.co.jp>

こんにちわ、桝形です。

http://archives.postgresql.org/pgsql-general/2003-05/msg01045.php
によると、PostgreSQL7.3.3がリリースされたそうですね。

HISTORYの内容を詳しく見ていないのですが、Changesの行が
それなりにあるようです。

--
Seiji Masugata <s.masugata ＠ digicom.dnp.co.jp>



From masae ＠ i-cbg.com  Wed May 28 18:04:09 2003
From: masae ＠ i-cbg.com (Masae Yoshida)
Date: Wed, 28 May 2003 18:04:09 +0900
Subject: [pgsql-jp: 30078] WindowsXP-JScript-PostgreSQL(Native版)で動かなくなった
Message-ID: <008c01c324f8$1bf02c40$6401a8c0@nob>

WindowsXP-JScript-PostgreSQL(Ver.7.2.1_Native版)にて
開発を行っておりますが、
今まで動いていたプログラムが急に動かなくなりました

プログラムは極めて単純なものですら動きません
例えば
・PostgreSQLのバージョン情報をブラウザに表示させるだけのもの
・DBをOPEN〜CREATE〜CLOSEするだけのもの
といったものです

いずれも先週までは何の問題もなく動いていたのですが
今週から急に動かなくなってしまいましたので
プログラムではなく環境の問題だと思うのですが原因がわかりません

ちなみにpsql でのDB操作は以前と変わらず行えます

環境に影響する作業では
Windows client for PostgreSQL(WPsql) などの
ツールをインストールしたぐらいですが、いずれも
インストール後 数日は動いていたので原因ではないと思うのですが・・・

PostgreSQLの再インストール，ODBC再設定，IE6.0SP2再インストールを
試みましたが解決しません

なにぶんWeb環境自体 初心者なもので
基本的な事もわかっていない状態ですが、
ご指導いただけないでしょうか


------------------------------
Masae Yoshida
mailto:masae ＠ i-cbg.com




From cdb01160 ＠ hkg.odn.ne.jp  Thu May 29 11:21:14 2003
From: cdb01160 ＠ hkg.odn.ne.jp (cdb01160)
Date: Thu, 29 May 2003 11:21:14 +0900
Subject: [pgsql-jp: 30079] \d　インデックス
Message-ID: <000001c32588$fa805440$1401a8c0@compevod300>

佐藤です。

7.3.2 の　psql　で、表題のバックスラッシュコマンドで、
インデックスの情報を表示させると、
（例）
Index "public.emp_pkey"
 Column |  Type
--------+---------
 id     | integer
primary key, btree, for table "public.emp"

と出てくるのですが、発行している　SQL　文を見ると
インデックスが付いているテーブル(emp)　の　namespace　を
調べていないようなのですが、
テーブルは、インデックスのある　namespace　に必ず、ある
と仮定されているのでしょうか?
それとも逆で、インデックスは、対象のテーブルと同じ　namespace　に
必ず作られる、なのでしょうか?
（どうも後者のような気がするけど、、、、、）

教えていただけないでしょうか?
よろしくお願いします。

以上　佐藤賢治




From saito ＠ inetrt.skcapi.co.jp  Thu May 29 14:39:22 2003
From: saito ＠ inetrt.skcapi.co.jp (Hiroshi Saito)
Date: Thu, 29 May 2003 14:39:22 +0900
Subject: [pgsql-jp: 30080] pgadmin-II 日本語対応版
Message-ID: <016701c325a4$a8ad74b0$1f324d80@w2k>

さいとうです。

お知らせをひとつ。

pgadmin-II の日本語対応をしています。
(手を出しておいて、しまったと思ったら後の祭りですね)

現在、cvs-currentからですのでBATA1の位置付けですが
だいぶ良くなってきましたのでお知らせします。

一応、本家のDaveさんに相談したら、勝手にこちらで管理して
もらったほうが良いとコメントをいただきました。
(patchを本体へ組み込むことは難があるので・・)
主力のFrankさんは今後国際化対応の案を持っているとのこと
で今後が楽しみです。

テストもおぼつかないのですが、いろいろ使って頂いてバグ出し
にご協力いただける方はぜひよろしくお願いします。
正版までにはこちら(日本語)も追いつきたいと思っています。

http://cre-ent.skcapi.co.jp/~saito/pgadmin/
からたどれます。
まだページもあちこち難がありますけど・・
どうぞよろしく。

※マシンも回線も貧弱ですのでアクセスに難があります。m(__)m




From shigeo ＠ tinyforest.gr.jp  Thu May 29 15:01:12 2003
From: shigeo ＠ tinyforest.gr.jp (Shigeo Kobayashi)
Date: Thu, 29 May 2003 15:01:12 +0900
Subject: [pgsql-jp: 30081] pg_dump  -?
Message-ID: <00f101c325a7$b534ac00$0201a8c0@ntfs1>

些細なことだし、既知かもしれませんが．．．

$ pg_dump -?
pg_dump dumps a database as a text file or to other formats.
...(略)...
If no database name is not supplied, then the PGDATABASE environment


「no database name is not supplied」って変ですよね？
バージョンは 7.3.2 です。


From yoneda ＠ kk-nik.co.jp  Thu May 29 15:42:01 2003
From: yoneda ＠ kk-nik.co.jp (Kazunori Yoneda)
Date: Thu, 29 May 2003 15:42:01 +0900
Subject: [pgsql-jp: 30082] Re: pgadmin-II 日本語対応版
References: <016701c325a4$a8ad74b0$1f324d80@w2k>
Message-ID: <3ED5ABB9.8070609@kk-nik.co.jp>

よねだです


> テストもおぼつかないのですが、いろいろ使って頂いてバグ出し
> にご協力いただける方はぜひよろしくお願いします。
> 正版までにはこちら(日本語)も追いつきたいと思っています。

早速ダウンロードしていじってみました
オブジェクトの作成アイコンの右にある三角をクリックすると
リストが表示されますが、アイコンをクリックすると

実行時エラー'62':ファイルにこれ以上データがありません

とダイアログ表示され、OKを押すとアプリケーションが終了して
しまいました
動作環境はWindowsXP SP1(Build2600.xpsp1.020828-1920)です


> ※マシンも回線も貧弱ですのでアクセスに難があります。m(__)m

　自宅サーバでダウンロード用の環境提供できますよ







From gontakun ＠ fish.co.jp  Thu May 29 16:13:28 2003
From: gontakun ＠ fish.co.jp (Chie.M)
Date: Thu, 29 May 2003 16:13:28 +0900
Subject: [pgsql-jp: 30083] Re: pgadmin-II 日本語対応版
In-Reply-To: <3ED5ABB9.8070609@kk-nik.co.jp>
References: <016701c325a4$a8ad74b0$1f324d80@w2k> <3ED5ABB9.8070609@kk-nik.co.jp>
Message-ID: <20030529155547.ACEB.GONTAKUN@fish.co.jp>

Chie.Mです。

私も早速ダウンロードしてみました。
環境はWindowsXP SP1　Professional SP1です。

ツールのオプションで「テキストの設定」を一旦欧文フォントにした後
再度、同画面を開いて日本語フォントを選択し、文字セットに日本語を
選択すると、文字セットの結果が欧文のままになってしまうようで
文字化けしてしまいます。

一旦終了して、再度立ち上げると、正常にフォントが
反映されるようになります。
文字セットを変更しなければ、正常に動作するようです。

# 元々オプションでログファイルの出力先の変更をしていたのですが
# ログファイルの出力先を変更したところ、なぜか勝手にフォントが
# 欧文になってまして、上記の挙動に気づきました。
# ログファイル出力先の変更でフォントがおかしくなる動作は
# その後再現しませんでした。

よろしくお願いします。
----------------------------
Chie.M <gontakun ＠ fish.co.jp>



From fujisue.masato ＠ nuflare.co.jp  Thu May 29 18:03:20 2003
From: fujisue.masato ＠ nuflare.co.jp (Masato Fujisue)
Date: Thu, 29 May 2003 18:03:20 +0900
Subject: [pgsql-jp: 30084] pgaccess のインストールエラーについて
Message-ID: <3ED5CCD8.5080108@nuflare.co.jp>

お世話になっております。藤末と申します。
先般より表題のインストールをやっていますが
下記のエラーが発生しうまく起動できません。
ご教授戴けますようお願い申し上げます。

一応、過去のMLを見て export DISPLAY=:0.0
等の設定や最初からpostgresでのLoginを実施
していますが現行と変わりないエラーを発しています。
尚、使っているShellはbashを使用

環境は下記の通りです。この環境設定はOSインストールの
ままです。OSは雑誌に付録されていたのものを使っています。
Redhat8.0　postgresql 7.2 / php4.2.2-8 /Apache 2.0.40-8

application-specific initialization faild: couldn't connect to disyplay 
":0.0" Error in startup script: 
invalid command name "image"     while executing
"image create bitmap dnarw -data  {
#define down_arrow_width 15
#define down_arrow_height 15
static char down_arrow_bits[] = {
    0x00,0x80,0x00,0x80,0x0 ...
(file "pgaccess.tcl" line 5)   


藤末





From saito ＠ inetrt.skcapi.co.jp  Thu May 29 18:07:55 2003
From: saito ＠ inetrt.skcapi.co.jp (Hiroshi Saito)
Date: Thu, 29 May 2003 18:07:55 +0900
Subject: [pgsql-jp: 30085] Re: pgadmin-II 日本語対応版
References: <016701c325a4$a8ad74b0$1f324d80@w2k> <3ED5ABB9.8070609@kk-nik.co.jp>
Message-ID: <02f001c325c1$ca7ea880$1f324d80@w2k>

さいとうです。

ありがとうございます。


> よねだです
>
>
> > テストもおぼつかないのですが、いろいろ使って頂いてバグ出し
> > にご協力いただける方はぜひよろしくお願いします。
> > 正版までにはこちら(日本語)も追いつきたいと思っています。
>
> 早速ダウンロードしていじってみました
> オブジェクトの作成アイコンの右にある三角をクリックすると
> リストが表示されますが、アイコンをクリックすると
>
> 実行時エラー'62':ファイルにこれ以上データがありません
>
> とダイアログ表示され、OKを押すとアプリケーションが終了して
> しまいました
> 動作環境はWindowsXP SP1(Build2600.xpsp1.020828-1920)です

なるほど、いろいろ各オブジェクトを操作していきながらアイコンの
ボタンを押すと出るようです。
-->あたりですね。(^_^;)

あと、個々の不具合はたくさん出そうなので、ここ(pgsql-jp)だと見
たくない人もいるかと思います(?)ので、安定するまで直接私宛に
直接で良いですよ。

>
>
> > ※マシンも回線も貧弱ですのでアクセスに難があります。m(__)m
>
> 　自宅サーバでダウンロード用の環境提供できますよ

ありがとうございます。
もすこし様子をみてダメだったら、そのときはどうぞよろしくお願いします。





From saito ＠ inetrt.skcapi.co.jp  Thu May 29 18:09:43 2003
From: saito ＠ inetrt.skcapi.co.jp (Hiroshi Saito)
Date: Thu, 29 May 2003 18:09:43 +0900
Subject: [pgsql-jp: 30086] Re: pgadmin-II 日本語対応版
References: <016701c325a4$a8ad74b0$1f324d80@w2k> <3ED5ABB9.8070609@kk-nik.co.jp> <20030529155547.ACEB.GONTAKUN@fish.co.jp>
Message-ID: <02f801c325c2$0b4e9b90$1f324d80@w2k>

さいとうです。

ありがとうございます。

> Chie.Mです。
> 
> 私も早速ダウンロードしてみました。
> 環境はWindowsXP SP1　Professional SP1です。
> 
> ツールのオプションで「テキストの設定」を一旦欧文フォントにした後
> 再度、同画面を開いて日本語フォントを選択し、文字セットに日本語を
> 選択すると、文字セットの結果が欧文のままになってしまうようで
> 文字化けしてしまいます。
> 
> 一旦終了して、再度立ち上げると、正常にフォントが
> 反映されるようになります。
> 文字セットを変更しなければ、正常に動作するようです。

こちらも、なるほどで
-->あたりでした。(^_^;)

先ほどと同じく、
個々の不具合はたくさん出そうなので、ここ(pgsql-jp)だと見
たくない人もいるかと思います(?)ので、安定するまで直接私宛に
直接で良いですよ。





From sugita ＠ sra.co.jp  Thu May 29 19:39:17 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Thu, 29 May 2003 19:39:17 +0900 (JST)
Subject: [pgsql-jp: 30087] Re: \d　インデックス
In-Reply-To: <000001c32588$fa805440$1401a8c0@compevod300>
References: <000001c32588$fa805440$1401a8c0@compevod300>
Message-ID: <20030529.193917.78721435.sugita@sra.co.jp>

  杉田です。

From: "cdb01160" <cdb01160 ＠ hkg.odn.ne.jp>
Subject: [pgsql-jp: 30079] \d　インデックス
Date: Thu, 29 May 2003 11:21:14 +0900

;;; 7.3.2 の　psql　で、表題のバックスラッシュコマンドで、
;;; インデックスの情報を表示させると、
;;; （例）
;;; Index "public.emp_pkey"
;;;  Column |  Type
;;; --------+---------
;;;  id     | integer
;;; primary key, btree, for table "public.emp"
;;; 
;;; と出てくるのですが、発行している　SQL　文を見ると
;;; インデックスが付いているテーブル(emp)　の　namespace　を
;;; 調べていないようなのですが、
;;; テーブルは、インデックスのある　namespace　に必ず、ある
;;; と仮定されているのでしょうか?
;;; それとも逆で、インデックスは、対象のテーブルと同じ　namespace　に
;;; 必ず作られる、なのでしょうか?
;;; （どうも後者のような気がするけど、、、、、）

  CREATE INDEX のマニュアルに以下のように書かれています。

    index_name

	The name of the index to be created.  No schema name can be included
	here; the index is always created in the same schema as its parent
	table.


Kenji Sugita                                      



From cdb01160 ＠ hkg.odn.ne.jp  Thu May 29 22:00:23 2003
From: cdb01160 ＠ hkg.odn.ne.jp (cdb01160)
Date: Thu, 29 May 2003 22:00:23 +0900
Subject: [pgsql-jp: 30088] Re: \d　インデックス
In-Reply-To: <20030529.193917.78721435.sugita@sra.co.jp>
Message-ID: <000001c325e2$44874c20$1401a8c0@compevod300>

佐藤です。

今読みました。どうもありがとうございます。

英文ですけど、
後半部分で、必ずテーブルと同じ　schema　に造られ、
前半部分で、勝手な　schema　を付けてはいけない。
と言う意味ですね。

ところで、この文書は、何処に入っているんでしょうか?
自分は、石井達夫さんのホームページをみて、
tar.gz からインストールしたのですが。

それから、今作っているプログラムは、
無料で利用できるようにするつもりです。

自分が　PostgreSQL　を使って何かを作ろうとした時に
最低限これぐらいの情報は見えていないとしんどい、
行ベースではなくて、文書ベースで　SQL　文を再利用したい、
やっぱり、テーブルのレコードは、直接触れた方が良い、、、、
等の思いで作っています。

ただし、作者は、本プログラムを利用して生じた、あるいは、
生じるかもしれない、あらゆる損害について、いっさい責任を持たない。
という、免責条項を付けます。
また、バグの修正、改良等を行う責任も負いません。
（生活がどうなるか分からないですから。）
まぁ、そんなに利用されるとは、思いませんけどね。

ありがとうございました。
これからもよろしくお願いします。
（これは、全員にかな?）

以上　佐藤賢治





From ams ＠ smile.ocn.ne.jp  Thu May 29 21:51:50 2003
From: ams ＠ smile.ocn.ne.jp (ams)
Date: Thu, 29 May 2003 21:51:50 +0900
Subject: [pgsql-jp: 30089] Re: pgaccess のインストールエラーについて
In-Reply-To: <3ED5CCD8.5080108@nuflare.co.jp>
References: <3ED5CCD8.5080108@nuflare.co.jp>
Message-ID: <20030529215150.2fb76066.ams@smile.ocn.ne.jp>

Thu, 29 May 2003 18:03:20 +0900 の刻
Masato Fujisue <fujisue.masato ＠ nuflare.co.jp>
は書かれました:
 
> 一応、過去のMLを見て export DISPLAY=:0.0
> 等の設定や最初からpostgresでのLoginを実施
> していますが現行と変わりないエラーを発しています。

多分、tcl/tk と postgreSQL の連携の問題だと思います。主因は
、RedHat 8.0 の tcl/tk の環境でしょう。

私は、RedHat 7.2base MLD-6 ですが、RedHat 本家から、srpm を
取って来て、バックポートしてます。

[maria ＠ maria maria]$ rpm -qa | grep postgres
postgresql-7.2.1-5
postgresql-perl-7.2.1-5
postgresql-tk-7.2.1-5
postgresql-contrib-7.2.1-5
postgresql-odbc-7.2.1-5
postgresql-python-7.2.1-5
postgresql-tcl-7.2.1-5
postgresql-docs-7.2.1-5
postgresql-libs-7.2.1-5
postgresql-server-7.2.1-5
postgresql-jdbc-7.2.1-5
postgresql-devel-7.2.1-5

という構成です。今回の問題には、PHP4 は恐らく関係無いでしょ
う。

[maria ＠ maria maria]$ rpm -qa | grep php
php-dbg-4.1.2-7
php-odbc-4.1.2-7
php-4.1.2-7
php-snmp-4.1.2-7
php-devel-4.1.2-7
php-pgsql-4.1.2-7
php-imap-4.1.2-7
php-ldap-4.1.2-7

で、大抵のものは無事ですから。tcl/tk は、日本語の入力に関し
て、また表示のサポートに関して、Vine 2.6rc1 の tcl/tk
8.0.5_jp をお勧めします。(FTP できます。)

RedHat 8.0 で使う場合、srpm を一旦解体して、Vine Patch をは
ずして (spec ファイルのパッチセクションから抜くだけ)リビルド
(# rpm -bb or -ba)すれば、動作します。このパッチは、 Vine 向
けのフォント指定に関するものなので、同じフォント構成になって
いない RedHat では、フォントのコンパウンドが出来ずアボートし
ます。尚、kinput2-wnn6 だけしか、入力は確認してません。

多分、IM のプロトコルの違うもの、ATOK X なんかは、対応してい
ません。Wnn7 は、大丈夫かもしれませんけど。

[maria ＠ maria maria]$ rpm -qa | grep tcl
postgresql-tcl-7.2.1-5
tcl-8.0.5_jp-10vl7mld6
tclx-8.0.5_jp-10vl3.mld6
itcl-3.0.1_jp-10vl8.mld6
[maria ＠ maria maria]$ rpm -qa | grep tk 
tk-8.0.5_jp-10vl6mld6
postgresql-tk-7.2.1-5
tkinter-1.5.2-28vl4

こういった構成になります。先に tcl/tk をビルド・インストール
して、それから、postgreSQL のリビルドをすれば、大丈夫です。

[maria ＠ maria maria]$ su -
Password: 
[root ＠ maria root]# su - postgres
[postgres ＠ maria pgsql]$ ls -a
. .bash_profile .psql_history  bin  
save .. 
initdb.i18n.bash_history  .bashrc                 
backups        logfile

[postgres ＠ maria pgsql]$ vi .bash_profile
--- .bash_profile
PGDATA=/home/pub/pgdata
[ -f $PGDATA/initdb.i18n ] &&  source $PGDATA/initdb.i18n
export PGDATA

# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs

echo "$PATH" |
grep -q -e "^$HOME/bin:" \
        -e ":$HOME/bin:" \
        -e "^$HOME/bin$" \
        -e ":$HOME/bin$" || PATH=$HOME/bin:$PATH

export PATH
unset USERNAME
---
[postgres ＠ maria pgsql]$ vi .bashrc
--- .bashrc
# .bashrc

# User specific aliases and functions
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'
# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

# PostgreSQL 7.2.1 の設定
export PGDATA=/home/pub/pgdata
export POSTGRES_HOME=/var/lib/pgsql
export PGLIB=/usr/lib/pgsql
export MANPATH=/usr/share/man
LANG="ja_JP.eucJP"
SUPPORTED="en_US:en:ja_JP.eucJP:ja_JP:ja"
SYSFONT="lat0-sun16"
SYSFONTACM="iso01"
export LANG LC_ALL LC_CTYPE LC_COLLATE LC_NUMERIC LC_CTYPE
LC_TIME
---

apache 1.3.7 との取り合わせで、PHP PostgreSQL も特に問題なく
動作し、pgaccess は、PostgreSQL 7.2.1 のものそのままです。
[maria ＠ maria maria]$ vi .pgaccessrc
---.pgaccessrc
pref,font_normal
{-Adobe-Helvetica-Medium-R-Normal-*-*-120-*-*-*-*-*}
pref,font_bold
{-Adobe-Helvetica-Bold-R-Normal-*-*-120-*-*-*-*-*}
pref,username {} pref,autoload {1}
pref,typecolors {black red brown #007e00 #004e00 blue orange
yellow pink purple cyan  magenta lightblue lightgreen gray
lightyellow} pref,font_fix
{-*-Clean-Medium-R-Normal-*-*-130-*-*-*-*-*}
pref,systemtables {0} pref,lastport {5432}
pref,tvfont {clean}
pref,lasthost {localhost}
pref,lastdb {/home/pub/test_db/test_smst}
pref,password {}
pref,rows {200}
pref,lastusername {maria}
pref,language {japanese}
pref,font_italic
{-Adobe-Helvetica-Medium-O-Normal-*-*-120-*-*-*-*-*}
pref,typelist {text bool bytea float8 float4 int4 char name
int8 int2 int28 regproc oid tid xid cid}
---

となってます。テスト用に使ってますので、localhost での利用で
す。(apache etc.)

> 環境は下記の通りです。この環境設定はOSインストールの
> ままです。OSは雑誌に付録されていたのものを使っています。
> Redhat8.0　postgresql 7.2 / php4.2.2-8 /Apache 2.0.40-8

RedHat 8.0 はお高いですから、逆に、RedHat 9 Pro あたりの正規
版だと、１万円台ですから、なるべくなら、こちらをお勧めします
が。最新の PostgreSQL では、pgaccess は、切り放されて、個別
メンテになってますよね？

ちなみに、apache の ドキュメントルート、PostgreSQL の DB 位
置などは、別パーティションに変更してますから、若干場所の相違
とかありますが、一般には変更不要でしょうから、そのままで大丈
夫なはずです。

> application-specific initialization faild: couldn't
> connect to disyplay ":0.0" Error in startup script: 
> invalid command name "image"     while executing
> "image create bitmap dnarw -data  {
> #define down_arrow_width 15
> #define down_arrow_height 15
> static char down_arrow_bits[] = {
>     0x00,0x80,0x00,0x80,0x0 ...
> (file "pgaccess.tcl" line 5)  

どういった、DB DATA にアクセスするのかに関して、pgaccess は
PostgreSQL の設定、運用が正しく出来ていてこそ、DB へ接続出来
ますから、こちらに不具合は無いでしょうか？

ちなみに、tcl のエラーが出てますね。これは、上記のように、
tcl/tk と PostgreSQL のリビルドで解決がつくと思います。

お試し版は、あくまでお試し版。また、X 自体がおかしい訳でも無
いと思いますが、なるべくきちんとライセンスのついたものの方が
、srpm も付属しますし、安心だとおもいますけど。。。ご事情も
あるでしょうけど。

ちなみに、RedHat の tcl/tk でも、表示だけは問題なく出来るは
ずなんですけどね。長文失礼しました。

---
ams
mailto:ams ＠ smile.ocn.ne.jp


From sugita ＠ sra.co.jp  Thu May 29 22:16:02 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Thu, 29 May 2003 22:16:02 +0900 (JST)
Subject: [pgsql-jp: 30090] Re: \d　インデックス
In-Reply-To: <000001c325e2$44874c20$1401a8c0@compevod300>
References: <20030529.193917.78721435.sugita@sra.co.jp>
	<000001c325e2$44874c20$1401a8c0@compevod300>
Message-ID: <20030529.221602.112612731.sugita@sra.co.jp>

  杉田です。

From: "cdb01160" <cdb01160 ＠ hkg.odn.ne.jp>
Subject: [pgsql-jp: 30088] Re: \d　インデックス
Date: Thu, 29 May 2003 22:00:23 +0900

;;; 英文ですけど、

  http://www.postgresql.jp/document/pg732doc/ に翻訳があります。

;;; ところで、この文書は、何処に入っているんでしょうか?

  ソースからインストールすると doc/html に入ります。


Kenji Sugita                                      



From saito ＠ inetrt.skcapi.co.jp  Fri May 30 02:18:02 2003
From: saito ＠ inetrt.skcapi.co.jp (Hiroshi Saito)
Date: Fri, 30 May 2003 02:18:02 +0900
Subject: [pgsql-jp: 30091] Re: pgadmin-II 日本語対応版
References: <016701c325a4$a8ad74b0$1f324d80@w2k>
Message-ID: <047401c32606$427d6800$1f324d80@w2k>

さいとうです。

取り急ぎ、早々と
Version 1.5.66-J03
でUPしました。
やはりみなさんに使っていただくことが大事ですね。
さっそく本体のpatchも併せてDaveさんに反映していただきました。
m(__)m

> さいとうです。
>
> お知らせをひとつ。
>
> pgadmin-II の日本語対応をしています。
> (手を出しておいて、しまったと思ったら後の祭りですね)
>
> 現在、cvs-currentからですのでBATA1の位置付けですが
> だいぶ良くなってきましたのでお知らせします。
>
> 一応、本家のDaveさんに相談したら、勝手にこちらで管理して
> もらったほうが良いとコメントをいただきました。
> (patchを本体へ組み込むことは難があるので・・)
> 主力のFrankさんは今後国際化対応の案を持っているとのこと
> で今後が楽しみです。
>
> テストもおぼつかないのですが、いろいろ使って頂いてバグ出し
> にご協力いただける方はぜひよろしくお願いします。
> 正版までにはこちら(日本語)も追いつきたいと思っています。
>
> http://cre-ent.skcapi.co.jp/~saito/pgadmin/
> からたどれます。
> まだページもあちこち難がありますけど・・
> どうぞよろしく。
>
> ※マシンも回線も貧弱ですのでアクセスに難があります。m(__)m




From toshitaka.iso ＠ hp.com  Fri May 30 06:17:46 2003
From: toshitaka.iso ＠ hp.com (Iso, Toshitaka)
Date: Fri, 30 May 2003 06:17:46 +0900
Subject: [pgsql-jp: 30092] PostgreSQLのバージョンアップに伴う注意点
Message-ID: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E023406A8@tkoexc02.asiapacific.cpqcorp.net>

こんにちは。

PostgreSQLのバージョンアップに伴う注意点をお教え下さい。

現状7.2.1で動いているPostgreSQLを7.3.2にVersionUpしようと
検討しています。

そこで質問なのですが、
手順としては
（0） pg_dumpで7.2.1のデータをバックアップ
（1） 7.3.2のインストール
（2） DB構築
（3） pg_restoreで7.3.2へリストア

だと思うのですが、そのほかに確認しなければならない点がありますでしょうか。

マニュアル等で調べた結果以下の注意点があるとのことですが・・・
・DUMP→RESTOREが必要
・外部参照整合性制約（Fkey）が削除される。ALTER TABLEで再作成行わないとダメ
・UNIQUE制約も削除されるらしい（実際は残っていた）
・initdb時に--no-locale を指定しないと、ソート順が狂う
・デフォルトで WITHOUT TIMEZONEとなったため、リストア時に注意が必要
	→ Timezone指定でスキーマを作って、データのみリストア
・pg_hba.confの形式が変わったため、7.2.1のものはつかえない。
etc…

また、7.3.2と7.2.1との性能面での大きな違いってなんなのでしょうか？
スキーマの導入/Lockの状況確認以外に性能的な面でどのようなところが
変わったのかお教えいただけたら幸いです。

以上です。


From yoneda ＠ kk-nik.co.jp  Fri May 30 10:13:20 2003
From: yoneda ＠ kk-nik.co.jp (Kazunori Yoneda)
Date: Fri, 30 May 2003 10:13:20 +0900
Subject: [pgsql-jp: 30093] Re: pgadmin-II 日本語対応版
References: <016701c325a4$a8ad74b0$1f324d80@w2k> <047401c32606$427d6800$1f324d80@w2k>
Message-ID: <3ED6B030.7030503@kk-nik.co.jp>

よねだです


> 取り急ぎ、早々と
> Version 1.5.66-J03
> でUPしました。


　素早いですね、夜中の２時ですか
　早速入れ替えて試用中、また不具合を見つけてしまいましたが
　後ほどまとめて・・・




From sugita ＠ sra.co.jp  Fri May 30 22:18:36 2003
From: sugita ＠ sra.co.jp (sugita ＠ sra.co.jp)
Date: Fri, 30 May 2003 22:18:36 +0900 (JST)
Subject: [pgsql-jp: 30094] Re: PostgreSQLのバージョンアップに伴う注意点
In-Reply-To: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E023406A8@tkoexc02.asiapacific.cpqcorp.net>
References: <EFCB1BFB1D978E4B8AD34BDDEEBA7B2E023406A8@tkoexc02.asiapacific.cpqcorp.net>
Message-ID: <20030530.221836.104036767.sugita@sra.co.jp>

  杉田です。

From: "Iso, Toshitaka" <toshitaka.iso ＠ hp.com>
Subject: [pgsql-jp: 30092] PostgreSQLのバージョンアップに伴う注意点
Date: Fri, 30 May 2003 06:17:46 +0900

;;; PostgreSQLのバージョンアップに伴う注意点をお教え下さい。
;;; 
;;; 現状7.2.1で動いているPostgreSQLを7.3.2にVersionUpしようと
;;; 検討しています。
;;; 
;;; そこで質問なのですが、
;;; 手順としては
;;; （0） pg_dumpで7.2.1のデータをバックアップ
;;; （1） 7.3.2のインストール
;;; （2） DB構築
;;; （3） pg_restoreで7.3.2へリストア
;;; 
;;; だと思うのですが、そのほかに確認しなければならない点がありますでしょうか。

  常日頃確認しなければなりません。

  ドキュメント化された、バージョンアップに必要な完璧な変更履歴はありません。ソー
スファイル中の HISTORY に記述されていないバグ修正や改善は必ずあります。以下の 
事をした上で、充分な移行のための検証をするのが確実です。

    1) ソースファイル中の HISTORY    

        全てのバグ修正や改善が記述されていると限りません。

    2) http://osb.sra.co.jp/PostgreSQL/7.3/

        HISTORY より詳しい事もありますし、そうでない事もあります。その事は明記
        してあります。今までも、マイナーリリースでも常にアップデートされると限
        りません。

    3) PostgreSQL のメイリングリストのウォッチ。

    4) リポシジトリのチェックインのトレース。


Kenji Sugita                                      



From hi_ono2001 ＠ ybb.ne.jp  Fri May 30 23:47:23 2003
From: hi_ono2001 ＠ ybb.ne.jp (Hisaji Ono)
Date: Fri, 30 May 2003 23:47:23 +0900
Subject: [pgsql-jp: 30095] PostGISのマニュアルの和訳
Message-ID: <00b301c326ba$635b5b90$818001db@webgis>

尾野です。

　徐々にですが、googleでもＰｏｓｔＧＩＳ関係の日本語ページが検索ヒット数が増
えつつあります。

　件名のサイトですが、以下のものがあります。


　http://www.ne.jp/asahi/free/hiroro/postgis/manual/

　http://kokogiko.net/index.php?%5B%5BPostGIS%5D%5D

　
　後者はWiki版で、加筆・修正ができ、BBSも持っています。



From formsoft ＠ tcct.zaq.ne.jp  Sat May 31 03:34:09 2003
From: formsoft ＠ tcct.zaq.ne.jp (Ryo Kunieda)
Date: Sat, 31 May 2003 03:34:09 +0900
Subject: [pgsql-jp: 30096] varchar属性の列の最大文字数の変更
Message-ID: <v04210a00bafd52de43bc@[192.168.128.10]>

お世話になります。

msg varchar(120)

と定義した列の長さを変更する必要が生じました。

ALTER TABLE で変更できないかと思いましたが、そのような用例はマニュアルにも記
載がないようです。
こういうことは可能でしょうか？

よろしくお願いします

----------------------------------------------------------------
formsoft ＠ tcct.zaq.ne.jp (FormSoftware)
Ryo Kunieda -  FormSoftware
Osaka, Japan　Tel:+81-6-6335-6266 Fax:+81-6-6335-6276
----------------------------------------------------------------


From watanove ＠ nifty.ne.jp  Sat May 31 10:42:39 2003
From: watanove ＠ nifty.ne.jp (渡辺伸雄)
Date: Sat, 31 May 2003 10:42:39 +0900
Subject: [pgsql-jp: 30097] レコード件数でパフォーマンスは落ちますか？
Message-ID: <3ED8088F.FF4C30A6@nifty.ne.jp>



渡辺といいます。

これからPostgreSQLを使おうと考えています。

皆さんのお使いのPostgreSQLでは実際にどの程度の規模でしょうか？

出来れば、テーブルを１００くらい、データ件数はそれぞれのテーブルに
ついて、多くて１０万件くらいの規模で使いたいのですが、

数万レコードのデータを扱うと、パフォーマンスが極端に落ちるようなことは
ないでしょうか？

もし、「私はこのくらいの規模で使っているけど問題ないよ」
というような、ご意見をお聞かせ頂ければと思い、投稿しました。

よろしくお願いします。





From mizusako ＠ southwave.co.jp  Sat May 31 11:55:34 2003
From: mizusako ＠ southwave.co.jp (Kiyohito Mizusako)
Date: Sat, 31 May 2003 11:55:34 +0900
Subject: [pgsql-jp: 30098] Re: レコード件数でパフォーマンスは落ちますか？
In-Reply-To: <3ED8088F.FF4C30A6@nifty.ne.jp>
References: <3ED8088F.FF4C30A6@nifty.ne.jp>
Message-ID: <20030531114419.ACAD.MIZUSAKO@southwave.co.jp>

こんにちは。mizusakoです。

　参考程度ですが
　テーブル数は、約１０００程、そのうち３分の１ぐらいのテーブルは、
約１０万以上のレコードデータを扱っていますが、パフォーマンスの低下は
それほど感じませんよ。
　テーブル設計がしっかりしていれば、そんなに気にするような事はないと
思います。

　サーバ環境
　　RedHat 7.3
　　PostgreSQL 7.2.3
　　CPU Celeron 350MHz
　　MEM 384MB
　　HDD 10GB

_/_/_/_/_/_/_/_/_/_/_/_/_/
Mizusako
mizusako ＠ southwave.co.jp
_/_/_/_/_/_/_/_/_/_/_/_/_/_




From imagawa ＠ okayama-coop.or.jp  Sat May 31 11:58:58 2003
From: imagawa ＠ okayama-coop.or.jp (今川　晃)
Date: Sat, 31 May 2003 11:58:58 +0900
Subject: [pgsql-jp: 30099] Re: レコード件数でパフォーマンスは落ちますか？
In-Reply-To: <3ED8088F.FF4C30A6@nifty.ne.jp>
References: <3ED8088F.FF4C30A6@nifty.ne.jp>
Message-ID: <20030531112804.A4CE.IMAGAWA@okayama-coop.or.jp>

> 出来れば、テーブルを１００くらい、データ件数はそれぞれのテーブルに
> ついて、多くて１０万件くらいの規模で使いたいのですが、
今時のサーバーなら何の問題もないでしょう。


> 数万レコードのデータを扱うと、パフォーマンスが極端に落ちるようなことは
> ないでしょうか？
ＳＱＬ記述方法、ＤＢ運用方法に問題がないとすれば、支障の出るほど
パフォーマンスが落ちることはないです。


> もし、「私はこのくらいの規模で使っているけど問題ないよ」
> というような、ご意見をお聞かせ頂ければと思い、投稿しました。
テーブル数　６１
ＤＢ全体の容量　３５Ｇ

巨大テーブルをcount(*)してみました
postgre=# select count(*) from ****;
  count
----------
 17987226
(1 row)

このテーブル、日々４万件づつ増え続けます。


ちなみに、６９８００円サーバーです。IDE-HDD 60G１本だけの非力
マシンです。それを２００名（最大同時接続は１５セッションくらい）
で使っています。


--
余談
メインマシンがクラッシュしてしまい、すでに１ヶ月６９８００円
サーバーで動かしていますが、クレームはありませんよ。

メインマシンの修理は手つかずです。少々焦っています。


----------------------------------
おかやまコープ　情報システム部
今川　晃　imagawa ＠ okayama-coop.or.jp




From watanove ＠ nifty.ne.jp  Sat May 31 13:38:04 2003
From: watanove ＠ nifty.ne.jp (渡辺伸雄)
Date: Sat, 31 May 2003 13:38:04 +0900
Subject: [pgsql-jp: 30100] Re: レコード件数でパフォーマンスは落ちますか？
References: <3ED8088F.FF4C30A6@nifty.ne.jp> <20030531112804.A4CE.IMAGAWA@okayama-coop.or.jp>
Message-ID: <3ED831AC.83DAA7F0@nifty.ne.jp>


Mizusakoさん、今川さん、こんにちは。
早速のレスありがとうございます。

mizusakoさんWrote

> 　テーブル数は、約１０００程、そのうち３分の１ぐらいのテーブルは、
> 約１０万以上のレコードデータを扱っていますが、パフォーマンスの低下は
> それほど感じませんよ。
> 　テーブル設計がしっかりしていれば、そんなに気にするような事はないと
> 思います。
>
> 　サーバ環境
> 　　RedHat 7.3
> 　　PostgreSQL 7.2.3
> 　　CPU Celeron 350MHz
> 　　MEM 384MB
> 　　HDD 10GB

よくパソコンの直販メールに入ってくる激安PCのスペックと比べたりすると
特に、高性能でないPCでも十分な性能が出るようですね。
Windowsでなくて、RedHatだということも高性能の理由の１つでしょうか。


今川さんWrote：

> テーブル数　６１
> ＤＢ全体の容量　３５Ｇ
>
> 巨大テーブルをcount(*)してみました
> postgre=# select count(*) from ****;
>   count
> ----------
>  17987226
> (1 row)

> 大きいテーブルですね。

数万件を心配する必要は全くないんですね。


お二人ともご指摘のように、PostgreSQLは件数にかかわらず高性能を
出してくれるが、テーブル設計や、運用方法に気を付けなければ






From watanove ＠ nifty.ne.jp  Sat May 31 13:45:35 2003
From: watanove ＠ nifty.ne.jp (渡辺伸雄)
Date: Sat, 31 May 2003 13:45:35 +0900
Subject: [pgsql-jp: 30101] Re: レコード件数でパフォーマンスは落ちますか？
References: <3ED8088F.FF4C30A6@nifty.ne.jp> <20030531112804.A4CE.IMAGAWA@okayama-coop.or.jp>
Message-ID: <3ED8336F.6FBF72C9@nifty.ne.jp>

渡辺です。
書きかけのメールを送ってしまいました。すみません。


Mizusakoさん、今川さん、こんにちは。
早速のレスありがとうございます。

mizusakoさんWrote

> 　テーブル数は、約１０００程、そのうち３分の１ぐらいのテーブルは、
> 約１０万以上のレコードデータを扱っていますが、パフォーマンスの低下は
> それほど感じませんよ。
> 　テーブル設計がしっかりしていれば、そんなに気にするような事はないと
> 思います。
>
> 　サーバ環境
> 　　RedHat 7.3
> 　　PostgreSQL 7.2.3
> 　　CPU Celeron 350MHz
> 　　MEM 384MB
> 　　HDD 10GB

よくパソコンの直販メールに入ってくる激安PCのスペックと比べたりすると
特に、高性能でないPCでも十分な性能が出るようですね。
Windowsでなくて、RedHatだということも高性能の理由の１つでしょうか。


今川さんWrote：

> テーブル数　６１
> ＤＢ全体の容量　３５Ｇ
>
> 巨大テーブルをcount(*)してみました
> postgre=# select count(*) from ****;
>   count
> ----------
>  17987226
> (1 row)

> 大きいテーブルですね。

数万件を心配する必要は全くないんですね。

お二人ともご指摘のように、PostgreSQLは件数にかかわらず高性能を
出してくれるから、テーブル設計や、運用方法が性能を左右するよ。
ということですね。


どうもありがとうございました。


今まで、Sybase　AnyWhere　と　Oracleを使った経験がありますが、
それぞれ少しずつ記法が違ったりしておもしろいのですが、
PostgreSQLもきっとそう言うことがいくつもあるんでしょうね。

PostgreSQLはこれから初めますので、またお世話になると思います。
よろしくお願いします。


From t-ishii ＠ sra.co.jp  Sat May 31 14:15:18 2003
From: t-ishii ＠ sra.co.jp (Tatsuo Ishii)
Date: Sat, 31 May 2003 14:15:18 +0900 (JST)
Subject: [pgsql-jp: 30102] Re: レコード件数でパフォーマンスは落ちますか？
In-Reply-To: <3ED8336F.6FBF72C9@nifty.ne.jp>
References: <3ED8088F.FF4C30A6@nifty.ne.jp>
	<20030531112804.A4CE.IMAGAWA@okayama-coop.or.jp>
	<3ED8336F.6FBF72C9@nifty.ne.jp>
Message-ID: <20030531.141518.104029719.t-ishii@sra.co.jp>

石井です．

> 数万件を心配する必要は全くないんですね。

一応PostgreSQLもデータベースですから:-)

> 今まで、Sybase　AnyWhere　と　Oracleを使った経験がありますが、
> それぞれ少しずつ記法が違ったりしておもしろいのですが、
> PostgreSQLもきっとそう言うことがいくつもあるんでしょうね。

SybaseとOracleの経験者とは心強い．そのうちPostgreSQLとの違いをレポート
していただけると面白いですね．

ところで，今月号(2003/6)の「日経システム構築」（旧「日経オープンシステ
ム」）ではPostgreSQL関連の記事がいろいろ取り上げられています．中には
OracleからPostgreSQLへの移行記事もあるので，参考になるのではないでしょ
うか．

1. 「早稲田大学のトラブルはSQL文のミスが原因」

   例のPostgreSQL+PHPを使った早稲田大学のシステムの原因をレポートして
   います．

2. マネースクウェア・ジャパン「インターネット外国為替取引システム」

   外貨取引システムをPostgreSQLで作って商用DBを使う場合に比べて数百万
   節約できたそうです．24時間稼働のシステムのため，HAソフトの
   LifeKeeperも併用しているらしいです．[pgsql-jp: 29651]で紹介されてい
   るシステムだと思います．

3. コニカフォトイメージング「コニカオンラインラボ」

   PostgreSQL事例として有名なコニカオンラインラボのセキュリティ対策．
   担当I氏の苦労がしのばれます．

4. ダイナック「Web受発注システム ニュー・セルベッサ」

   OracleからPostgreSQLへの移行事例．PL/SQLとPL/pgSQLの違いが面白かっ
   たです．

5. 無償DBMSのPostgreSQL

   手前みそで恐縮ですが，私が書いたPostgreSQLの管理面での解説記事です．
--
Tatsuo Ishii


From tom ＠ asakawa.ne.jp  Sat May 31 15:36:54 2003
From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa)
Date: Sat, 31 May 2003 15:36:54 +0900
Subject: [pgsql-jp: 30103] Re: PostgreSQLのバージョンアップに伴う注意点
In-Reply-To: <20030530.221836.104036767.sugita@sra.co.jp>
Message-ID: <451BADA0-9332-11D7-8FFC-0003931E2C60@asakawa.ne.jp>

あさかわです

> ;;; PostgreSQLのバージョンアップに伴う注意点をお教え下さい。
> ;;;
> ;;; 現状7.2.1で動いているPostgreSQLを7.3.2にVersionUpしようと
> ;;; 検討しています。
>

7.2系列（それ以前もだと思う）は
数値型フィールドに対して、NULL文字列の代入が可能ですが
7.3系列は
数値型フィールドへの、NULL文字列の代入がエラーになります。
（NULLの代入はできます)

＃ということで、７.2->7.3で、泣きました。










From watanove ＠ nifty.ne.jp  Sat May 31 15:36:38 2003
From: watanove ＠ nifty.ne.jp (渡辺伸雄)
Date: Sat, 31 May 2003 15:36:38 +0900
Subject: [pgsql-jp: 30104] Re: レコード件数でパフォーマンスは落ちますか？
References: <3ED8088F.FF4C30A6@nifty.ne.jp>
		<20030531112804.A4CE.IMAGAWA@okayama-coop.or.jp>
		<3ED8336F.6FBF72C9@nifty.ne.jp> <20030531.141518.104029719.t-ishii@sra.co.jp>
Message-ID: <3ED84D76.1458107F@nifty.ne.jp>

渡辺です。
石井さん、レスありがとうございます。


> 一応PostgreSQLもデータベースですから:-)

無償というのが、いまだに気になっていたものですから



> SybaseとOracleの経験者とは心強い．そのうちPostgreSQLとの違いをレポート
> していただけると面白いですね．

石井さんが満足できるようなものは、ちょっとごにょごにょです。


> ところで，今月号(2003/6)の「日経システム構築」（旧「日経オープンシステ
> ム」）ではPostgreSQL関連の記事がいろいろ取り上げられています．中には
> OracleからPostgreSQLへの移行記事もあるので，参考になるのではないでしょ
> うか．
>
> 5. 無償DBMSのPostgreSQL
>
>    手前みそで恐縮ですが，私が書いたPostgreSQLの管理面での解説記事です．

手元にあったので、読みました。
　（ちゃんと読んでおきなさい！ってかんじですが）

大きなシステムでも十分な実績があると言えるんですね。
石井さんの記事では４CPUが必要な場合はどうかな、と言うことが書かれてましたが

私が心配している規模（１テーブル数万件）では、４CPUが必要になるのは相当未来
の事のようです。　

安心して使わせて頂きます。

ありがとうございました。

これからもよろしくお願いします。




From fkit.s ＠ sys238.jp  Sat May 31 22:28:07 2003
From: fkit.s ＠ sys238.jp (fumiyaKitamura)
Date: Sat, 31 May 2003 22:28:07 +0900
Subject: [pgsql-jp: 30105] Re: varchar属性の列の最大文字数の変更
In-Reply-To: <v04210a00bafd52de43bc@[192.168.128.10]>
Message-ID: <B7533B10-936B-11D7-BE3A-000393C7A1A2@sys238.jp>

キタムラです。


ALTER TABLEではないですが

create table HOGE_TEMP as select * from HOGE;
drop table HOGE;
create table HOGE(
  ...
  ...
  MAG VARCHAR(400),
  ...
)
insert into HOGE select * from HOGE_TEMP;
drop table HOGE_TEMP;


とやって再作成では駄目でしょうか？

あと、他のDBへの移行を考えているのでなければ、PostgreSQLでは
文字列の格納はVARCHARよりTEXTの方がいいようです。


On 2003.5.31, at 03:34 Asia/Tokyo, Ryo Kunieda wrote:

> お世話になります。
>
> msg varchar(120)
>
> と定義した列の長さを変更する必要が生じました。
>
> ALTER TABLE で変更できないかと思いましたが、そのような用例はマニュアルにも記
> 載がないようです。
> こういうことは可能でしょうか？
>
> よろしくお願いします

=================<F.Kitamura>=================
E-Mail  : fkit ＠ sys238.jp
---
The greatest enemy of man is alcohol.
But, The Bible tells us to love our enemy.
==============================================



From to-seki ＠ u01.gate01.com  Fri May 16 07:03:09 2003
From: to-seki ＠ u01.gate01.com (Toshio Seki)
Date: Fri, 16 May 2003 07:03:09 +0900
Subject: [pgsql-jp: 31868] excampusのインストール
Message-ID: <000901c31b2d$c51bfd50$0200a8c0@mbsite>

初めての投稿です、関と申します。
http://www.excampus.org/　からeラーニングのオープンソース「excampus」をダウンロードしてインストールしました。どうにか
インストールは終わったと思ったのですが
プロフィールの変更で下記のエラーが出てしまいました。

Warning: pg_query(): Query failed: ERROR: syntax error at end of input at
character 49 . in /home/elearning/exCampus/exCampus/lib/memberlibs.phps on
line 114

Warning: Cannot modify header information - headers already sent by (output
started at /home/elearning/exCampus/exCampus/lib/memberlibs.phps:114) in
/home/elearning/exCampus/exCampus/member/profileedit.php on line 28Warning:
pg_query(): Query failed: ERROR: syntax error at end of input at character
49 . in /home/elearning/exCampus/exCampus/lib/memberlibs.phps on line 114

Warning: Cannot modify header information - headers already sent by (output
started at /home/elearning/exCampus/exCampus/lib/memberlibs.phps:114) in
/home/elearning/exCampus/exCampus/member/profileedit.php on line 28

私の環境はRedhat9 + Apache1.3.29 + PHP4.3.4 + Postgres7.4 です。PHPは4.2.3も
試したが同じ現象です。
よろしくお願いします。



From to-seki ＠ u01.gate01.com  Fri May 16 00:21:17 2003
From: to-seki ＠ u01.gate01.com (Toshio Seki)
Date: Fri, 16 May 2003 00:21:17 +0900
Subject: [pgsql-jp: 31875] Re: excampusのインストール
References: <000901c31b2d$c51bfd50$0200a8c0@mbsite>
Message-ID: <000e01c31af5$a19e9460$0200a8c0@mbsite>

関です。
レスポンスをもらえないので自己レスします。

> プロフィールの変更で下記のエラーが出てしまいました。
>
> Warning: pg_query(): Query failed: ERROR: syntax error at end of input at
> character 49 . in /home/elearning/exCampus/exCampus/lib/memberlibs.phps on
> line 114
>
> Warning: Cannot modify header information - headers already sent by
(output
> started at /home/elearning/exCampus/exCampus/lib/memberlibs.phps:114) in
> /home/elearning/exCampus/exCampus/member/profileedit.php on line 28

この種のエラーが立た場合の解決方法のヒントだけでももらえないでしょうか？


> 私の環境はRedhat9 + Apache1.3.29 + PHP4.3.4 + Postgres7.4 です。PHPは4.2.3
も
> 試したが同じ現象です。

上記アプリケーションは下記オプションを付けてコンパイルしています。
Postgres:--enable-multibyte=EUC_JP
PHP:--with-pgsql  --with-apxs --enable-mbregex --enable-mbstring

よろしくおねがいします。