PostgreSQL Part.9

1 ：2012/05/26 〜 最終レス ：2013/01/14

PostgreSQL (ぽすとぐれすきゅーえる, ぽすとぐれす) について語るスレです。
●関連サイト
PostgreSQL 本家
http://www.postgresql.org/
日本PostgreSQLユーザ会
http://www.postgresql.jp/
ドキュメント
http://www.postgresql.jp/document/current/html/
ダウンロード
http://www.postgresql.jp/PostgreSQL
Let's Postgres (ポータルサイト)
http://lets.postgresql.jp/
pgFoundry
http://pgfoundry.org/
●前スレ
PostgreSQL Part.8
http://toro.2ch.net/test/read.cgi/db/1294641578/

2 ：

●過去スレ
PostgreSQL 2テーブル目　(WebProgから派生)
http://pc8.2ch.net/test/read.cgi/db/1056944337/
PostgreSQL ＆ pgsql-jp ML 3テーブル目
http://pc11.2ch.net/test/read.cgi/db/1079771059/
【Windows】 PostgreSQL8　Part.1 【対応】　(実質part4)
http://pc11.2ch.net/test/read.cgi/db/1102247223/
PostgreSQL Part.5
http://pc11.2ch.net/test/read.cgi/db/1196512717/
PostgreSQL Part.6
http://pc11.2ch.net/test/read.cgi/db/1224318817/
PostgreSQL Part.7
http://hibari.2ch.net/test/read.cgi/db/1256300618/
PostgreSQL Part.8
http://toro.2ch.net/test/read.cgi/db/1294641578/
●関連過去スレ
■　　　PostgreSQLのことならここで聞け　　　■　(初心者part1)
http://pc8.2ch.net/test/read.cgi/db/1056960249/
■　　　PostgreSQLのことならここで聞け　　　■　(初心者part2)
http://pc8.2ch.net/test/read.cgi/db/1091523132/
PostgresSQLについて語ろう　(雑談part1)
http://pc8.2ch.net/test/read.cgi/db/1056992724/
PostgreSQLについて語ろう where OID=2::oid　(雑談part2)
http://pc8.2ch.net/test/read.cgi/db/1136805513/
●関連スレ
2ch検索
http://find.2ch.net/index.php?STR=PostgreSQL
WebProg/PostgreSQL 2テーブル目
http://pc11.2ch.net/test/read.cgi/php/1047317680/

3 ：

テンプレはコピペだがよかったかな?

4 ：

>>前スレ1000
構文解析が済んでいるからって、処理順をすべて無視して良いとは限らないでしょう。
つーか、なぜあなたは自分レス>>前スレ978の不都合さを無視するの?

5 ：

そこは、内部的にそう展開されても問題ないといいたいんだろう

6 ：

みなさん、ま、まさか
case文とか
countとか、sumとかの集約関数さえも知らん奴を相手にしてたのでは
Rクを語るならSQLの基本的な仕様を理解してからにして欲しいですな

7 ：

それを抜きにしても(抜いちゃいかんけど)、
言語設計(概念レイヤとでも言うか)と実装レイヤがごっちゃなのよね、あの子。

8 ：

言語仕様あっての実装であって、
そのための字句解析、意味解析なのに、
その仕様である実行順も各句の役割も無視してる
具体例に対してちゃんと検証しようともしてない。まあSQL知らないからしょうがないのかも知れないが、それならそれなりの応対があるだろうに。

9 ：

いちおつ

10 ：

SQL信者の必死さに涙が止まらない
>>4
>>>前スレ1000
>
>構文解析が済んでいるからって、処理順をすべて無視して良いとは限らないでしょう。
処理順を無視してなんかないですよ。where句から処理が始まったとして、それより前に別名を展開する処理を追加しただけですね。
どこをどうみたら、処理順をすべて無視したと感じたのでしょうか。
>つーか、なぜあなたは自分レス>>前スレ978の不都合さを無視するの?
978ってこれ？
978> > 例えば、初心者が何故以下のような文でエラーが起きるか理解できなくなる。
978> > SELECT COUNT(foo) AS cnt FROM hoge WHERE cnt > 2 GROUP BY bar;
978> この例だと WHERE COUNT(foo) > 2 としたところで何の違いもない。
これについてなら、すでに983にあるとおり。
983> 何の違いもなくエラーが出るよってことでいいのかな
WHERE cnt > 2 も WHERE COUNT(foo) > 2 も同じようにエラーになる。それだけ。「不都合」って言ってるけど何が不都合？

11 ：

技術的に可能ならそのまま仕様にすれば良いと思ってるのか？

12 ：

>>10
信者ってw
丁寧に汚い言葉を使わずに、丁寧に返信していたつもりだが、
もう、そう言うようにしかとっていただけないのなら、勝手にしてください。
あ、最後に
>>983> 何の違いもなくエラーが出るよってことでいいのかな
>>WHERE cnt > 2 も WHERE COUNT(foo) > 2 も同じようにエラーになる。それだけ。「不都合」って言ってるけど何が不都合？
そういう意味ね。失礼、取り違えてました。

13 ：

闇雲に否定はしないけど、難しいだろうなと思うのはこういうの。
select
a as b,
b <- selectで別名解決はしないままでよい？
from tableA
where b = 3; <- 別名と、本来のカラム名との区別はどうやってつける？

14 ：

select
rand()*3::integer as id
,val
from
a
where
id < 100
これは？aテーブルにid列があったらどうする？
selectは、物理テーブルと関係のないを作り出したり、
複数列から一つの列を作り出したり出来る。上の人のエイリアスがかぶる場合ってのもそうだし、人間様がどれが欲しいのか理解できるのか？
それとも全部エラーにしちゃうのか？現在の標準仕様ならばなんの不都合もなく実行できるのだが。

15 ：

すまんpostgresだとrandom()だな
select floor(random()*1000)とかと読み替えてくれ

16 ：

もし、前スレ>>990で書いてたようにもとのカラム見ないで
エイリアス優先とかルール作っちゃうと意図したことができなくなるよ
case文で例を、
念のために、aテーブルの構成は
id | subid1 | subid2 | val1 | val2
select
case
when val2 > 100 then subid1
else subid2
end as id
,val1
from
a
when
id > 50
aテーブルのidが50以上の行を抽出して、その行に対してだけcaseの条件文から新しいid列、val1列を導きたいんだけど、
勝手にselect句のcaseが適用されちゃう、どう解決しよう？

17 ：

>>10
＞それより前に別名を展開する処理を追加しただけですね。
正しく動作させるには「前」じゃなくて「スコープの外側」な
from
{
　　�@
　　where
　　{
　　　　�A
　　　　select
　　　　{
　　　　　　�B
　　　　}
　　}
}
「別名を展開」する命令を�@〜�Bのどこに書けばいいか分かるだろ？
Ｃ言語なんかだとどんな馬鹿でも「前」に書けば自動的にスコープ内に入るから
君みたいなプログラミング初心者ほど「前」に書けばいいという固定観念に縛られて
こういうミスをやってしまうんだよ
君はもっと勉強して脳みそを鍛えたらＳＱＬを使いこなせるんじゃないかなあ

18 ：

ちょっと訂正
君はもっと勉強して脳みそを鍛えたらＳＱＬ「も」使いこなせるんじゃないかなあ

19 ：

SQLにスコープという概念が存在するとは思わなかった。

20 ：

>>19
SELECT table1.column1, table2.column2　FROM　table1 INNER JOIN table2 ON　・・・
テーブル名で修飾してるのはスコープの概念そのものなんだが理解できるかい？

21 ：

処理順無視してないとか言って
SELECT COUNT(foo) AS cnt FROM hoge WHERE cnt > 2 GROUP BY bar;
これを
WHERE COUNT(foo) > 2
こんな展開したら明らかに処理順無視してるじゃねーか・・・
WHEREの方が先に動くっていってんだからよう
たまたまWHERE句でcount関数が使えないだけだろ

22 ：

>>19
サブクエリとか分かりやすいスコープ

23 ：

>>21
彼は、そういうのはエラーになればいいだろ、展開して問題ないものだけ動けばいいんだという言い分だと思う。
展開して問題ないものの判断ができない場面があることに気づいてないみたいよ。

24 ：

>>10は非手続き型言語をまったく理解してない
そもそも　列名　AS 別名　とはselect句の出力の属性を宣言しているのであって、プロシージャ（手続き）を宣言しているわけではない
それにも関わらず「それより前に別名を展開する処理を追加しただけですね。」というのはプロシージャを追加したということになり
もはや非手続き型言語ではない
そんな基本的な矛盾に気がつかないようではプログラマとして致命的だ

25 ：

なんだ、楽しみにして帰ってきたのにもう来ないのか？なかなか強烈だったから振り返ってみよう。
いつも過疎で平穏な、DB板のPostgreSQLスレに彼は来た。
「試したところ、エラーになりました。
psql=> select id as ticket_id from tickets where ticket_id < 10;
ERROR: column "ticket_id" does not exist」
どうにもこのエラーが受け入れられないらしい。
思えば初めから他人の話にはほぼ全て否定的であった。
前スレ>>957,968,971,975,978
（そもそもやつがsqlに対して無知だからおかしてる間違いだろ？
字句解析・意味解析の知識はあるか知らんが（ほんとか？評価順の重要さも分かっていないようだが）、
SQLの知識が無いという自覚なしに、誰もsqlを持ち上げたりしてる訳じゃなく仕様を読めって言ってるだけなのに）そう俺は思った。
>SQL信者の必死さに涙が止まらない
あとからこんな言葉が吐かれることになるとは、
この時はまだ思いもしなかった。この言葉は、俺の今後の人生をきっと豊かにしてくれるだろう。
前スレ>>990
>構文解析や意味解析についての、簡単でもいいので基礎知識があれば、
>別名をwhere句で使えるようにするのが特に困難なことではないはずだ、
>というのがすぐにわかるんだけど。
>たぶん構文解析についての基礎知識がないやつが、SQLの仕様書がどうのこうの
>いっているのだろう。
>なぜそういう仕様になっているのかが聞かれているのに、SQLの仕様を読めと
>答えてるのは滑稽すぎる。
最高に恥ずかしい！！！この晩はこれをつまみに一杯やった。
評価順があると、具体例挙げてどう動くか考えろと、言っても無駄だった。
前スレ>>1000
>だーかーら、そのまえにSQLの構文解析と意味解析をしてるでしょうが。
>構文解析　→　意味解析　→　FROM句→WHERE句→SELECT句・・・
>　　　　　　　　　　　　^^
>　　　　　　　　　　　ここで構文解析木を操作して別名を展開すればいいだけ。
>なんでwhere句やselect句の順番にこだわるの。whereやselectの処理に入るまえに別名を展開すればいいだけなのに、なんでこんなことがわからないの。
>なんで結果が変わると思ったの？
とか頓珍漢なこと言っちゃって結局クエリの内容見ないのだ。
（なんで順番にこだわんないの?）よいこのみんなは思ったはずだ。
その後も同じような主張を繰り返した。
（自信満々なのはいいが、人の話をちゃんと聞かないようじゃ何のために質問しに来たんだか…
何かもっと面白い提案でもでるのかと思ってたのに…まぁこんな日も有るか）
大変ワイルドな出来事でした。

26 ：

なっが。
てか、元質問者と同一認定していいのか？

27 ：

気付いて、顔から火吹いて逃げちゃったんだろうか。
正直なところどう感じたのかをお伺いしたい。

28 ：

あれほど自信満々だったら、標準化してるISOなり
pgsql-jpで石井さんに詰め寄るくらいして頂きたかった。

29 ：

ここで復讐を果たす為に専門的知識を必死に習得してるのではなかろうか

30 ：

いや、きっとmysqlスレで同じ事を質問する
「試したらエラーになりました。簡単なことなんですけど、どうしたらできますか？」ってね
もはや何かの陰謀に違いない

31 ：

mysqlだったらあの程度の出鱈目仕様、もう実装してんじゃね？

32 ：

死者に鞭打つ真似はおよしなされ

33 ：

叩くほうがここまで必死なのにはわけがあるんだろ。

34 ：

9.2　32コアまでスケールは凄いな。
index only scanも導入されるし、
カスケードレプリケーション、range型とかも。
もうあれだな。

35 ：

客にバージョン上げようぜっていいやすくなるな

36 ：

やっぱりポスグレは最先端なのですね！
マイエスキューエラーに馬鹿にされなくて済みます

37 ：

ちょっと前までMySQL使ってて、ポスグレちょぼちょぼ使い出したとこやけど、
WITHが便利過ぎてﾜﾛﾀ。
とあるテーブルAから、条件に合うレコード削除して
その内容を「削除済み」用のテーブルBに書いて、
ついでにテーブルCの該当レコードのフラグカラムを書き換え。
これが一文一発で出来て、明示的なトランザクション制御要らず。
気持ち良過ぎやろ。

38 ：

writableCTEはpostgres独自だから意識して使うんだぞ

39 ：

インストーラーで簡単セットアップのWebベースPostgreSQL管理「TeamPostgreSQL」
http://www.moongift.jp/2012/06/20120604-3/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+moongift+%28MOONGIFT+-+%3F%3F%3F%3F%3F%3F%3F%3F%3F%3FIT%3F%3F%3F%3F+-%29&utm_content=LocalHost

40 ：

Windowsの32bit版と64bit版のベンチマーク比較の資料ってどこかにあるんでしょうか？

41 ：

CentOS5.8とPostgreSQL8.4を使っています
logファイルにSQLが出力されるのを抑止し
たいのですが、どのようにすればよいで
しょうか？

42 ：

postgresql.confをいじれ
見てわかんなかったらマニュアルを読め

43 ：

>>41
http://www.postgresql.jp/document/8.4/html/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN
log_min_error_statement PANIC
かな

44 ：

いやまあ、log_statement だと思うけど
わざわざ設定しないと出ないはずだが。

45 ：

うん、デフォだと出ないよね

46 ：

alter table テーブル名 add column カラム名
するときに、場所って指定できますか。
たとえばカラム「age」をカラム「name」と「gender」のあいだに追加したいとか。

47 ：

>>46
普通はテーブル作りなおさないとできないんじゃなかったかな。
RDBはもともとカラムの位置を気にしないものだし。

48 ：

SELECT時に順番決めるしね。
*指定したくて気になるならView作ればいいし、
DROPして作りなおすのもありっちゃあり

49 ：

並べ替えが出来るdbもあるのよね
postgresの場合は出来たら便利なのは分かってるけど他に優先度が高いのがあって、手掛ける人がいないってどこかで読んだような

50 ：

これだ
http://wiki.postgresql.org/wiki/Alter_column_position

51 ：

１・２・３

52 ：

順番が気になる人は、ほとんど初心者しかいないから
対応するのもアホくさいと思うがなあ

53 ：

>>52
変更コストがどうかと言う問題はあるけれど。
20列のテーブルで3-5列に処理区分1,処理区分2,処理区分3とあり、
処理区分4だけが21列目。しかも、20列目の入力時刻の後になるというのは
いろいろな意味で好ましいことではない。

54 ：

その考えの先には、
　　:
　予備1　　varchar(100)
　　:
　予備2　　varchar(100)
　　:
があったりして。

55 ：

>>53
すべてのユーザがviewを通してすべてのテーブルを管理しているという訳では
ないからね。やはり列の並び順も少なくとも管理しやすさには大きく関係する。
一般にはね。

56 ：

pg9.1.4のpg_trgmを使った全文検索の速度について
CREATE TABLE documents
(
id serial NOT NULL,
document text,
CONSTRAINT pky PRIMARY KEY (id )
);
CREATE INDEX idx
ON documents
USING gin
(document COLLATE pg_catalog."default" gin_trgm_ops)
documentカラムには、
平均1000文字の英文が100万行格納されています。
上記の状態のテーブルに次のSQLを実行しました。
--「keyword etc」が含まれているかどうか確認
SELECT EXISTS(
SELECT * FROM documents WHERE document_text like E'%keyword etc%'
);
実行した結果は、0.5秒〜300秒を超えてタイムアウトするものまで様々です。
(「keyword etc」の場合10.8秒でした。)
設定ファイルの編集やSQLの改善でもう少し早くすることはできないでしょうか。
ちなみに、実行している間は、実行しているコアのCPU使用率が100%になっています。

57 ：

速度改善とは関係ないけど、EXISTS使うと、1件見つかった時点で切り上げそうな気がする。

58 ：

pg_trgmを使いたいのは複数の単語からなる語句を文章中から検索したいから？
トリグラムを使わずに
CREATE INDEX idx ON documents USING gin(to_tsvector(document));
として、
SELECT EXISTS(
SELECT * FROM documents WHERE document @@ ts_query('keyword & etc') and document like E'%keyword etc%'
);
としたらどうなる？

59 ：

SELECT EXISTS(
SELECT * FROM documents WHERE to_tsvector(document) @@ ts_query('keyword & etc') and document like E'%keyword etc%'
);
のまちがいだった。

60 ：

>57
ありがとうございます。
１件(１行)でもキーワードがあるかどうかを確認したいので、
そのように１件見つかった瞬間に処理を切り上げてもらえるのが助かります。
>58
ご提案ありがとうございます。
なるほど、一度vector検索してから
連語があるか確認するのですね。
一度テストしてから、またお返事させていただきます。

61 ：

1000文字英文100万行くらいなら全然対したことなさそうだけどな
trgrm自体の検索は大体そこそこ早いんだよ
でもインデックスでヒットした後に実テーブル確認しに行ったりするとそこで速度が落ちる。
だからヒット数が多ければ多いほど遅くなるよ。 特にメモリに実テーブルがのっていない場合。
そんな感じじゃない？>>56
そうであれば、差し支えなければそもそもginでヒットする件数をgin_fuzzy_search_limitで抑えちゃうことができるのでそれを検討してみては？ここに書いてあるよ
www.postgresql.jp/document/9.1/html/gin-tips.html

62 ：

56です。返答が遅くなって済みません。
>>58-59
いくつか検証してみましたが、
今より高速になるものもあれば、むしろ速度が落ちるものもありました。
原因としては、
to_tsvector(document) @@ ts_query('keyword & etc')
の段階で該当する行が大量にあった場合、
そこからは、シーケンシャルなlike検索が行われているような気がします。
（ただ、実行計画では、BITMAP HEAP SCANとなっていますので、
　インデックスを使ってなお遅いということなのかも知れません。）
>61
gin_fuzzy_search_limitを1に設定して実行してみました。
確かに実行速度は、早くなったのですが、有るはずの文字列がないと判断されるようになりました。
gin_fuzzy_search_limitを0、または9999999等の十分大きな値に設定すれば、
>56のクエリで[True]が帰ってくるSQLでも、
gin_fuzzy_search_limitの値を小さく（例えば1や10）にすると
[FALSE]が帰ってきます。
where句でヒットした行数を絞って返すという認識なのですが、
（1000件ヒットしても、gin_fuzzy_search_limitが10ならば、10件しか返さない）
間違っておりますでしょうか？

63 ：

そこで設定した数字は正確に有効な行数を表す訳じゃないのよ。
なので小さく設定しすぎると、正しい結果が帰らないこともある。
事情を説明するのが面倒（というかソース追う時間が無くて自分も正確に把握してない）
なので、興味があれば調べてみて。
ということで、速度(と結果)が妥協できるところで、
小さく設定するのがよし。

64 ：

あ、たくさんの行がヒットすると遅いってのは、
　ginインデックスのみからwhere句条件で探す（これは早い。転置なんで当たり前）
　→正しいかどうかヒープ（メモリに納められてる実タプル（もちろん無ければディスク読む））をもう一回条件で調べる
（bitmapの説明は省いた）
て手順だから。プランでrecheckって出てるでしょ？
インデックスっていつも正しい情報が入ってるって限らないのよpgは

65 ：

os: CentOS 5.2 locale=C
postgresql 9.1.2 locale=C, DBの文字コードはUTF-8
接続クライアント
a. WindowsXP上のTeraTerm UTF-8
b. JDBC type4接続 Java文字コードはUTF16BE
2点質問があります。
(1) a.において、psqlが出力するエラーメッセージが文字化けします。
SELECT結果(UTF-8)は問題ありません。
文字化けを解消する、またはメッセージを英語にする方法をご存知であれば教えてください。
(2) b.において、JAVA例外(PSQLException)のメッセージが文字化けします。
ログファイルの文字コードはUTF-8。
SELECT結果(UTF-8)は問題ありません。
こちらも文字化けを解消する、またはメッセージを英語にする方法をご存知であれば教えてください。

66 ：

追記です。
osのタイムゾーンは日本です。
よろしくお願いします。

67 ：

http://www.postgresql.jp/document/current/html/multibyte.html#AEN24155
を参照して文字コードを指定する必要があるのかもしれない。

68 ：

エラーメッセージの話でしょ？
CentOS 5.2 locale=C
て言ってるけど、具体的には何で判断して
どこに設定されてる？LC_ALL？LANGUAGE？LANG？
とりあえずそこら辺を確認して
それからpostgresql 9.1.2 locale=Cていってるけど、
postgresqlはソースから入れたんだよね？
ちゃんとインストールしたpostgresqlが動いてる？
（たまに、インストールしたのにシステムにデフォルトで入ってるpostgresあげてる人とかいるので)
何処に設定したものからCって判断してる？
"実際に動いてるpostgresの"postgresql.confで
lc_messages = 'C'
lc_monetary = 'C'
lc_numeric = 'C'
lc_time = 'C'
になってるかい？
psqlでの
select name, setting from pg_settings where name like 'lc\_%';
の結果
name | setting
-------------+---------
lc_collate | C
lc_ctype | C
lc_messages | C
lc_monetary | C
lc_numeric | C
lc_time | C
みたいにconf(と思っているもの)と一致してるかい？

それを確認した上で、
export LANG=C
してpsqlコマンド使っても化け文字？

69 ：

お二方ありがとうございます。
おかげさまで(1) については解決しました。
原因は、トラブルシュートのテスト用に用意した、意図的に壊した設定ファイルが読まれていました。
正しい設定ファイルに置き換えることで解決しています。
(2) については状況が変わりません。
どうも本体ではなくJDBCドライバの問題のような気がします。

70 ：

Win7でレプリケーションうまくいかないなぁ。

71 ：

pg_dumpでデータ以外のみをエクスポートする方法はないでしょうか？

72 ：

＞データ以外のみ
schemaのことだね？
オプションにあるべ

73 ：

-s

74 ：

ありがほー

75 ：

http://www.postgresql.jp/document/pg823doc/html/datatype-numeric.html
ここに
integer 4バイト
bigint 8バイト
とありますが、これは64bit版でもそうなのでしょうか。

76 ：

>>75
YES. 32/64bitで差はない。

77 ：

>>76
ありがとうございます。
いちおう確認ですけど、x86_64ならintが64bitだから、PostgreSQL 64bit版でもintegerとbigintに性能の差はないと考えていいですよね？

78 ：

CPUのビット数やコンパイラのintの長さと
DBのINTに関係は無いよ、環境に寄らずMDBSが決めたサイズになる。

79 ：

(C)コンパイラのintのサイズにしても、
64bit環境だからって64bitとは限らないし。
というか32bitのままって方が多そう。

80 ：

Postgres9.1.0をソースコンパイルでOSX山ライオンにインストールしようとした。
が、
configure: error: in `/Users/jiro/Downloads/postgresql-9.1.0':
configure: error: C compiler cannot create executables
と文句を言われ途中で止まってしまいます。
対処法をご存知のかたがいましたらご教授願います。

81 ：

あげます。

82 ：

試しに9.1.4ダウンロードしてビルドしてみたけど、問題なかったよ。
Xcodeとコマンドラインツールは入れてるよね？

83 ：

postgresqlでLEFT OUTER JOINをしたいんだけど
片方のテーブルの型がtextでつなげる方の型がinteger
おまけにtextの方が0で頭が埋ってる10桁なんだがどうやるんですか？
教えて下さい偉い人
SELECT * FROM a LEFT OUTER JOIN b ON a.accountcode = to_char(b.id, '0000000000');
これじゃなぜかだめっす

84 ：

どうだめだったの？
a.accountcode：：INT とかでいかない？

85 ：

これでどう？
to_char(b.id, 'FM0000000000');
偉くないので分からないけど、こっちの方が良いかもしれない。
to_char(b.id, 'FM0999999999');

86 ：

不慣れなplpgでトリガ関数いっぱいつくらにゃあかんのですが、
デバッグのいい方法ないですかね？
PgAdmin�Vだと関数のデバッグのみでトリガ関数のデバッグができないようでして

87 ：

RAISE文を使ってprintfデバッグくらいしか思いつかないなぁ。

88 ：

そうですかー。んじゃ今日もトリガと格闘してきます。

89 ：

textsearch_sennaで30個にパーティションに分割したテーブルを
selectすると、必ずpostgresのプロセスごと落ちるんだけど、
何か方法ないですか？
分割した個々のテーブルにならselectしても落ちないんですが、
個々のテーブルをselectするSQLを5つくらいunionでつなげてもやっぱり落ちます...

90 ：

9.2が出たら起こしてくれ

91 ：

PostgreSQL 9.2 RC1 Available for Testing
Posted on 2012-08-27
だいぶ先かな

92 ：

マイエスキューエラーに虐められた時に言い返す方法教えて

93 ：

>>92
比較スレへどうぞ。
MySQL vs PostgreSQL Part2
http://toro.2ch.net/test/read.cgi/db/1123011800/

94 ：

>>92
飼い殺し乙
とか言ってやれ。事実だし。

95 ：

MySQLだと1つのDBに一人のユーザを閉じ込めるっていう隔離ができるんですが、
PostgreSQLでもできますか？
やりかた教えてください＞＜；

96 ：

initdbで作成するとき、場所変えればいい。
複数作れる。同時に起動するときは、それぞれのpostgresql.confで
ポート変えないとならんけどね。

97 ：

superuserにしなければいいんでは？

98 ：

>>96 のようにDBクラスタごと分ける
pg_hba.conf でログインできるDBを制限
スキーマ + ロールでアクセス制限
どれでもお好きに。ちなみに、MySQLのDB ≒ Postgresのスキーマ だと思ったほうがよいかも。

99 ：

idをserialで作ったテーブルがあるんですけど、これをあとからbigserialに変えることはできますか。
alter tableだとsequenceが変わらないような気がします。

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

Oracle 質問総合スレ8 (954)
ADO DAO など接続方法について (360)
XML統合スレッド (391)
【無料DB】OpenOffice2.0?Base【Accessｲﾗﾈ】 (596)
彼女にINSERT権限がありません (816)
数十メガバイトのファイルをどんどん格納できるDB (202)
--log9.info------------------
【警視庁】警察事務職員を目指す人 その７【県警】 (254)
静岡県庁・静岡県内市町役場 その12 (969)
■□■東京消防庁 最終合格者待機スレその4■□■ (438)
首都を守るプライド�T類スレpart6 (294)
技能・現業職員採用情報 part39 (606)
【元TAC】吉井英二の必勝倶楽部【元LEC】 (287)
【東京と】 町田市役所スレPart4 【神奈川の狭間】 (642)
【Ａ方式】船橋市職員採用試験　part10【Ｂ方式】 (520)
最終合格からの不採用に怯えるスレ【地方公務員】 (300)
■■■■■航空管制官採用試験Part12■■■■■ (644)
★ 海上保安学校学生採用試験(海上保安庁) その22★ (446)
【国�Tに次ぐ】地上 ｖs 労基 vs 裁事【公務員】 (254)
一日の勉強成果を報告するスレ70時間目 (857)
北海道の市町村スレ part10 (680)
平成24年度 裁判所事務官一般職　Part15 (712)
沖縄公務員試験 総合スレ その10 (796)
--log55.com------------------
雑談　冗談じゃないよ
雑談　BushなBull Shitに
雑談　2018年8月29日(水)
雑談　粉R　170
雑談　2018年8月30日(木)
★働きたくないでござる・・・其之弐佰 漆拾漆
俺達の人生って何だったんすかね？　１０７週目
【全頭高】顔でか頭でかに苦しむ孤男7【目下】