PostgreSQL Part.11©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>113
最近は差を詰めてきてるよね
とはいえ大規模になればまだまだOracle
>>114
PostgreSQLにも一応マテリアライズドビューあるでしょ
>>115
金払わないとパッチすらくれず、払っててもバグ修正してくれないけどな >>116
>金払わないとパッチすらくれず、払っててもバグ修正してくれないけどな
何その塩対応 >>116
ポスグレのそれを使った事ないって意味ですよ。
Orackeの現場では頻繁に聞こえますね。でも結構トラブッてるようなw バグが修正されてユーザのコードが動かなくなったとき
危険なコードを書くのが悪いと言われるのがPostgres
専用の互換性パッチの見積もりをくれるのがOracle >>119
なるほど
ボラクル体質をとても明快に理解できた
そんでもってどっちがまともかは言わずもがなだな バージョンあがって動かなくなるなら、バージョンあげないだけだよ
そもそも特に困ってないのにバージョンあげるわけないだろう
ミドルウェアのバージョンが変わるなんて、5年ごとのリプレースだけだよ そのバグ修正の内容がセキュリティ脆弱性の改善でなければな データベースサーバにセキュリティパッチあてるわけないだろ （データベースサーバはインターネッツに公開なんかしないんだから、セキュリティパッチあてる必要もないだろ）
ということかな OSのパッチなのかRDBMSのパッチなのかでもかわってくるｗ おまえらPostgreSQLにセキュリティのためにパッチなんて当てたことあるの？
UPSERT使いたいからバージョンあげるとかだったらあるかもだけど
セキュリティなんて考えたこともない >>139
・パラレルクエリ
・同期レプリケーション / シャーディング (postgres_fdw)
・全文テキスト検索 (たぶん日本語はダメ)
って感じ？
結構なパワフルユーザ向けだな。まぁ基本はやり尽くしているんだろうけど どうしてPostgreSQLって本屋さんに本が全然ないんですか？
MySQLはたくさんあるのに 最新のシーラカンス本の対応バージョンは8くらいだったっけ？ CTEやCONFLICTについてがっつり書いてるような本が欲しい となるとやっぱ最新マニュアルしかないわなぁw
そこそこ良く書けてるしわかり易いと思う。 おすすめの記事ってどこかある？
ブロガーさんやニュースサイトでも何でも
PostgreSQLについて情報が集まるようなとこ探してる さあ、みんな今こそ売り込みの絶好のタイミング
自社のURLを貼るんだ エセ左翼の目的は、わざと突っ込みどころが多い主張をすることで自分たちへ注意を向けさせ、
カルトへ向かう非難の矛先を逸らすこと。
国益に反することを言ったり、主張が食い違うもの同士の対立を煽ろうとするので放置し難いが、
主義思想についての洗脳を受けているわけではなく、フリをしているだけなので、
言い負かされてもダメージを負った様子もなく、論点をすり替えられるかスルーされる。
まともに相手をしてはならない。 pgAdmin3 は日本語で使ってるとなんかのコマンドが日本語で流れてエラーになった記憶があるので、それ以来ずっと英語で使ってる 来週末のPGConf.Asia、みんなは行くかい？
http://www.pgconf.asia/JP/ PostgreSQLって、OrderByを書かないと・・・・
毎回違う並び順になるの？
それとも、PrimaryKey順になるの？ 不定だわな。たとえ何かの順に並んでたとしても信用出来ない。 >>162
一々ソーティングしなくていいから少しでも速く、省メモリで結果返して欲しいって時に勝手にソーティングされたら寧ろ迷惑だと思わないかい？
ソーティングは通常ではなくオプションとすべきだ 不定だけど、大体はINSERTした順になることが多い
UPDATEしたりするとそれが最後になったりするので
id順とはいえない
もちろん出てくる順番を当てにしちゃいけないｗ で、なんでそんな物理的事情で並んだ順で返すのかって言ったら、『一々ソーティングしなくていいから少しでも速く、省メモリで結果返して欲しいって時に勝手にソーティングされたら寧ろ迷惑だろ、ソーティングは通常ではなくオプションとすべきだ』ってことでないの？ >>170
クラスタ化インデックスだとpk順になる。 >>170
そんなのどんなRDBMSでも同じで、実装を考えれば、そうなるだろうが。 >>171
違う。RDBのレコードはソート指定をしないかぎり不定というのが標準SQLでの仕様だから。 PHP+PostgreSQLで運用する場合、元号の処理ってどうしてる？
自分でしか使わないシステムなので、極力西暦で通すか、どうしても必要な場合は1988引いてるけど（基本的に昭和のデータは扱わない）、今度の改元がなぁ >>176
データベースだというのに西暦→和暦マスタテーブルを作ろうという発想がないことに驚く >>176
昭和99年とかの特殊な要件がなければ内部は西暦、外部とのやり取り時に変換が普通かと >>176
表示なり入力なりエンドユーザに一番近いところで変換したいな
そもそも元号という「汚い」ものを可能な限り扱いたくないし、
Postgres用の変換はおそらく自作が必要だが、PHPやJS用なら適当に拾ってこれるから >>177
マスタテーブルだけで変換しようとすると、年の途中での改元に対応しないといけないんで、1日あたり1レコード要るんじゃね？
100年で36,525か36,524になっちゃう >>180
アホくさ。なんで年号が変わらない部分の日の単位でデータを持つんだよ。
それじゃあ自分の生年月日を書くのに今日からさかのぼって一日ごとに列挙して書くようなもんだろw 明治:1868-01-25 〜 1912-07-29
大正:1912-07-30 〜 1926-12-24
昭和:1926-12-25 〜 1989-01-07
平成:1989-01-08 〜
これをどうＵＩに反映するかは、各自の考え方だろう。 インデックスについて教えてください。
調べましたが「検索が早くなる場合もあるらしい」くらいしか分かりませんでした。
・ インデックスは作成するだけでよいのか？
検索時に作成したインデックスを指定したりしなくてよいのか。
調べた限り指定する方法がなかったため、作成するだけで効果があるように見えた。
・ REINDEXでのロック時の挙動
インデックスがロックされると聞いた。
インデックスがロックされるだけで検索自体は可能なのか。
・ とりあえずインデックスを作成しておけばよいのか？
インデックスがそんなに便利なものなら、ハードディスクの容量が許す限り、
検索しそうなものは片っ端からインデックスを作成しておけばよいのか。 >>186
> ・ インデックスは作成するだけでよいのか？
はい。
インデックスを使った方が検索コストが低い場合は、自動的に使われます。
> ・ REINDEXでのロック時の挙動
> インデックスがロックされるだけで検索自体は可能なのか。
いいえ。検索もブロックされます。
通常はreindexする必要はありません。
将来、reindexが必要だと感じたら（容量が増大したなどの場合）、どう対処するのが
良いか検索するとよいです。
> ・ とりあえずインデックスを作成しておけばよいのか？
いいえ。
インデックスがあるということは、INSERT/DELETEのときにデータ本体だけでなく
インデックスそのものも更新する必要があります。
単純に言えば、処理時間が増えるということです。
不要なインデックスは生成しないようにするのが良いです。 日本語扱うならencodeはCだろって言う人を結構見る気がしますが、なぜutf8じゃ駄目なんでしょうか？ 例えばこの人
http://soudai1025.blogspot.jp/2015/03/postgresqlunicode-6.html
> なお、検証した環境のPostgreSQLのlocale指定はC（nolocale)としています。
> （日本語を扱う場合はほとんどの場合はCを指定するでしょうし） えっ・・・
今まで作ったシステム、全部utf8にしてきてしもうた・・・ encodeとlocaleは別だぞ。
encode=utf8 かつ locale=C が推奨なのはよく見る。
Linux (glibc) はlocaleの実装をサボっているので、C以外に設定しても性能が落ちるだけで何の利点もない。
Windowsなら文字列の比較やソートに差が出るので、用途に適して選べばいい。 initdb --encoding=UTF8 --no-locale ←これが基本かなと >>193
Linuxでも当然ながら差が出る。
なぜなら、文字コードは辞書順には並んでないから。 >>196
どんな文字コードでも漢字の並び順は、日本人が見ても意味のある順番になってないからな。 >>196
Linuxもまともになったのか？
昔使ったときはlocale=ja系でも変わらず文字コード順に並べられたんだが >>198
「辞書順」の正しい定義を知らないけど、少なくとも文字コード順には並ばないよ。
create table foo(s text)に、漢数字の'一'から'九'をインサートし、以下のクエリを実行。
select array_agg(s) from (select s from foo order by s) as t;
locale=C -> {一,七,三,九,二,五,八,六,四} -- 文字コード順
locale=ja_JP.UTF-8 -> {一,九,五,三,四,七,二,八,六} -- 辞書(?)順 文字コード順でも辞書順でも、それを正解とするかどうかは要件次第。
ちなみに漢数字は、訓読み順で並んでいる。 >>199
理解した。Linuxでも順序は変わるね。
ひらがな／カタカナの濁／半濁の扱いは今でも差があるようだ。設計思想？互換性？
msvcrt: ハはバばパぱ
glibc : はばぱハバパ
環境依存が怖い。要件次第だが、自前で「ふりがな」列を用意したほうがマシだな。 他人に公開する予定の無い、自分専用のwebサイトを作る場合でもSQLインジェクション対策はしておいた方がいいよね？
クラスを転用するときに問題になるし、悪意が無くてもエラーのもとだし >>203
言語によるけど今時パラメータクエリぐらいは使えるだろうから普通にパラメータクエリでやるわな
あとから見てもその方がわかりやすいし >>205
PHPで言えば、pg_query_params()とか？ phpって対策されていないやつ
非推奨じゃなかったっけ
おいらはPDOでやってるかな ぽすとぐれすきゅーえる
ぽすとぐれすえすきゅーえる TIMESTAMP (WITHOUT TIMEZONE)とCURRENT_TIMESTAMPについて教えてください。
INSERTにてCURRENT_TIMESTAMPで入れたあと、SELECTで取り出すと日本時間になっています。
どの時点で日本時間になっているのでしょうか？
1. CURRENT_TIMESTAMPの時点ではJSTだが、INSERTするときにJSTがUTCに変換されて保存され、
SELECTで取り出すときにシステムの時刻を見て+0900されている
2. CURRENT_TIMESTAMPの時点ではJSTで取得されるが、
元々これにタイムゾーンのデータはなく、そのまま保存され、
SELECTで取り出すときは同じシステム時刻を使ってるからたまたま同じタイムゾーンとして取得されている
3. CURRENT_TIMESTAMPの時点ではUTCで取得され、保存もUTCだが
SELECTで取り出すときはシステム時刻を参照して勝手にJSTにしている
4. その他の未知の仕組み >>210
http://www.postgresql.jp/document/current/html/datatype-datetime.html
> 通常timestamp without time zoneの値はtimezoneのローカル時間としてみなされる
とあるから、言葉通りだとするなら：
・INSERTするときに時刻の値だけを保存する (+0900を無視)
・SELECTするときに現在のタイムゾーン扱い (+0900を追加)
SET TIMEZONE TOしながら試してみれば検証できるかも >>210
まず前提として、without time zoneをselectした結果にはtime zone情報はないのだから、UTCもJSTもない。
次にcurrent_timestampは、tz情報付きのデータ。
それをwithout time zone絡むにインサートすると、tz情報は切り捨てられる。（たとえば、"2017-05-12 18:00:00")
そのデータを、日本で取得しようがアメリカで取得しようが、tz情報なしの"2017-05-12 18:00:00"が取得される。
つまり、アメリカで取得した人は、現地時間の"2017-05-12 18:00:00"だと見えるということ。 >>211-212
ありがとうございます。
世界向けのSNSを作ろうとしたのですが、これがネックで
時間部分の設計ができない状態でした。
助かります。 お世話になります。
psql で database ごとに history を分けて表示したい (\s) のですが、
(他の databae の history を表示したくない)
どうやったらいいのでしょうか？
よろしくお願いします。 historyって、homeの .psql_history 出してるだけだからなあ
db切り替えるたびにリネームするとか？ ■ このスレッドは過去ログ倉庫に格納されています
