フォーラムへの返信
-
投稿
-
かやはらさんこんにちは。
TIMESTAMP WITH TIME ZONEは、タイムゾーンの情報(+09とか)付きで日付時刻を保持するというより、タイムゾーンを適宜変換して扱ってくれる型です。
https://www.postgresql.jp/document/9.4/html/datatype-datetime.html によると、以下のような入出力の動作をします。
>timestamp with time zoneについて内部に格納されている値は常にUTCです（協定世界時、歴史
>的にグリニッジ標準時GMTとして知られています）。 時間帯が明示的に指定された入力値は、その
>時間帯に適したオフセットを使用してUTCに変換されます。 入力文字列に時間帯が指定されていな
>い場合は、システムのTimeZoneパラメータに示されている値が時間帯とみなされ、timezone時間
>帯用のオフセットを使用してUTCに変換されます。
>timestamp with time zone値が出力されると、この値はUTCから現行のtimezoneに変換され、そ
>の時間帯のローカル時間として表示されます。 他の時間帯での時間を表示するには、timezoneを
>変更するか、あるいはAT TIME ZONE構文（項9.9.3 を参照）を使用します。
つまり、クライアントで入力した日付時刻はタイムゾーンを考慮してUNIZ TIME（多分）などに変換されて格納され、別のクライアントからクエリーされたときはそのクライアントのタイムゾーンに合わせた形で日付時刻表現に変換されて表示されます。
例えば、タイムゾーンが UTC のクライアントで 2018/11/11 0:00:00 を挿入（又は更新） した場合、 日本(JST)のクライアントでクエリーすると 2018/11/11 9:00:00 として表示されます。
ちなみに、to_char(current_timestamp, ‘YYYY/MM/DD HH24:MI:SS TZ’) 等とすると、to_char()は当然サーバーで処理されることになるので、サーバーのタイムゾーンで文字列に変換されることになるようです。Shunさんこんにちは。
データがない場合もエラーにはならないはずなのですが…。データベースの種類などをお教えいただけますでしょうか？。
とりあえず、一括エクスポート中にエラーが起こった場合は、テーブル名が分かるようにしたいと思います。
みやさんこんにちは。
何かプリンタ絡みで何か環境による問題があるのではないかなという気もしますが、よくわかりません。
OSに深く食い込むようなドライバを含むわけでもないので A5:SQL Mk-2がOSの機能まで巻き込んで不具合を起すというのもなかなか不可解に思います。
通常使うプリンタのプリンタドライバを再インストールするとか、通常使うプリンタを別のものに変更するなどすると何か変化はないでしょうか？。
あとは、C:\program files 配下はディレクトリのリダイレクトなども発生してよくわからないので、別のフォルダに配置してみるとよいかもしれません。（あまり関係ない気もします）
過去に Windows 10では「通常使用するプリンタ」絡みの仕様変更（不具合？）もあったりしたのですが、Windows 7だとこれも関係ないような気がしますし。
おのがわっちさんこんにちは。
とりあえず今のところ、こちらでは再現できていません。Azure環境は試せていないのですが、おそらく関係はないのではと考えています。
ただ、先頭しか実行されないというのはどのような状況でしょうか？。なにかエラーやメッセージ類は表示されたりするのでしょうか？。あと、範囲選択して実行すると、動作モードにかかわらず、そこだけ実行になるのですが、関係ありませんでしょうか？。
いぬぽんさんこんにちは。
はい、こちらでも再現しました。やはり、画面更新タイミングの問題で、ひとつ前に表示していたタブの処理時間を表示してしまっているようです。次のベータ版で修正したいと思いますので少々お待ちください。
井上さんこんにちは。
はい、今のところ、「テーマカラー」の機能ではいわゆる「ダークテーマ」は再現できません。
「テーマ」の機能で、例えば「Carbon」等を選ぶと、近いものになるかと思いますが、テーマ機能は多少「重く」なり、altキーの動作などが微妙に変わるのでこれはこれで検証してから使ったほうが良いかと思います。
ytさんこんにちは。
A5:SQL Mk-2でPostgreSQLに接続するとき、使用しているライブラリの制限（仕様？）でtext型に空文字列を設定できず、NULLとして解釈するようです。どうも内部的にCLOBとして扱っていることに何か関係がありそうです。
とりあえずの解決策としてはオプションダイアログで「PostgreSQL」タブの「TEXT型をラージオブジェクト(CLOB)型ではなく、文字列型として扱う。」をチェックすると、空文字列を設定できますが、8192バイトまでしか扱えなくなるのでデータによっては注意が必要です。
しなもんさんこんにちは。
select句にあるコメントは行の後ろにあるとみなして整形してしまっていました。
また、コメントを行末に持ってくる前提で、必要に応じてカンマとコメントの位置を入れ替えるロジックが動作していました。以下のようなSQLをうまく成形するための機能です。
整形前
123selectAAA, -- コメント１BBB -- コメント２整形後（列の前にカンマが来るような設定で整形するとき「コメント１」とカンマの位置が入れ替わる）
123selectAAA -- コメント１, BBB -- コメント２列名の前にコメントがあることを想定していないため、この機能が原因でうまく成形できていなかったようです。
とりあえず、次のベータ版でそのあたりを制御できるようにオプションを付けたいと思います。
けんすけさんこんにちは。
すみません、私の勉強が追いつかず、PostgreSQLのパーティション機能を試せていません。とりあえず、
https://www.postgresql.org/docs/10/static/catalog-pg-class.html
の記述から、パーティションテーブルもテーブル一覧の列挙対象にすることにします。
次のベータ版で修正したいと思いますので少々お待ちください。ももたさんこんにちは。
new TABLE名でテーブルが作成できるのは初めて聞いたのですが、どのRDBMSでしょうか？。一切の命令ができないというのはどのような状態でしょうか？。そのテーブルにSELECT等も実行できないということでしょうか？。
ともぞうさんこんにちは。
はい、プロシージャのソースは、information_schema.ROUTINES の ROUTINE_DEFINITION から取得しているのですが、どうも MySQL 8.0 になって、型の仕様が少し変わったのかもしれません。次のベータ版で修正したいと思いますので少々お待ちください。
いそがいさんこんにちは。
たしかに、CREATE TABLEの順序は制御できたほうが良いですね。
テーブル名（エンティティ名）順もそうですが、依存関係でも何か制御できたほうが良いのでは？とも考えています。
ちょっと考えてみたいと思いますので少々お待ちください。
Mさんこんにちは。
はい、現象を確認しました。どうも、論理名表示にしたときにウィンドウの上の方に論理テーブル名を表示しているのですが、これが関係しているような気もします。ちょっと修正したいと思いますので少々お待ちください。
論理名で表示が初期表示のオプションもちょっと考えてみたいと思いますので少々お待ちください。
