表 9.33は、日付/時刻型の値の処理で使用可能な関数を示しています。詳細は、以下の副節で説明します。
表 9.32は、(+、*等の)基本的な算術演算子の振舞いを説明しています。
書式設定関数については9.8を参照してください。
8.5を参照して、日付/時刻データ型についての背景となっている情報に精通していなければなりません。
加えて表 9.1で示す通常の比較演算子が日付/時刻型で利用できます。
日付とタイムスタンプ(時間帯付きあるいは時間帯なし)はすべて互換性がありますが、時刻(時間帯付きあるいは時間帯なし)と時間間隔は同じデータ型の値同士だけが比較可能です。
時間帯なしのタイムスタンプと時間帯付きのタイムスタンプを比較する際には、前者の値はTimeZone設定パラメータで指定された時間帯にあるものと仮定され、後者の値(すでに内部的にはUTCです)と比較するためにUTCに変換されます。
同様に、タイムスタンプと比較する際には、日付の値はTimeZone時間帯の午前零時であると見なされます。
以下のtimeもしくはtimestamp型の入力を受け取る関数および演算子は全て、実際には2つの種類があります。1つはtime with time zone型またはtimestamp with time zone型を取るもので、もう1つはtime without time zone型もしくはtimestamp without time zone型を取るものです。
簡略化のため、これらの種類の違いは個別に示していません。
また、+と*演算子は可換な2項をとります(例えばdate + integerとinteger + date)。こうした組み合わせは片方のみ示します。
表9.32 日付/時刻演算子
演算子 説明 例 |
|---|
日付に日数を加算
|
時刻間隔を日付に加算
|
日付に時刻を加算
|
時間間隔を加算
|
時間間隔をタイムスタンプに加算
|
時間間隔を時分に加算
|
時間間隔の符号を反転
|
日付を減算し、経過日数を返す
|
日付から日数を減算
|
日付から時間間隔を減算
|
時分を減算
|
時分から時刻間隔を減算
|
タイムスタンプから時刻間隔を減算
|
時間間隔を減算
|
タイムスタンプを減算(
|
時間間隔にスカラーを乗算
|
時間間隔をスカラーで除算
|
表9.33 日付/時刻関数演算子
関数 説明 例 |
|---|
引数間の減算。日数だけでなく年と月を使用した「言葉による」結果を生成
|
|
現在の日付と時刻(文実行中に変化する)。9.9.5を参照。
|
|
現在の日付。9.9.5を参照
|
現在の時刻。9.9.5を参照。
|
精度を限定した現在の時刻。9.9.5を参照。
|
現在の日付と時刻(現在のトランザクションの開始時)。9.9.5を参照。
|
精度を限定した現在の日付と時刻(現在のトランザクションの開始時)。9.9.5を参照。
|
|
指定した起源に合わせて指定の時間間隔に切り捨てます。9.9.3を参照してください。
|
タイムスタンプの部分フィールドの取得(
|
時間間隔の部分フィールドの取得(
|
|
指定された精度で切り捨て。9.9.2参照。
|
指定された時間帯において指定された精度で切り捨て。9.9.2参照
|
指定された精度で切り捨て。9.9.2参照。
|
タイムスタンプの部分フィールドの取得。9.9.1を参照。
|
時間間隔の部分フィールドの取得。9.9.1を参照。
|
|
日付が有限(+/-無限でない)かどうかの検査
|
タイムスタンプが有限(+/-無限でない)かどうかの検査
|
時間間隔が有限かどうかの検査(今の所常に真)
|
30日周期を月単位に変換して時間間隔を調整
|
間隔を調整し、24時間を日に変換
|
|
|
現在の時刻。9.9.5を参照。
|
精度を限定した現在の時刻。9.9.5を参照。
|
|
現在の日付と時刻(現在のトランザクションの開始時)。9.9.5を参照。
|
精度を限定した現在の日付と時刻(現在のトランザクションの開始時)。9.9.5を参照。
|
年、月、日フィールドから日付を作成(負の年はBCを意味します)
|
年、月、週、日、時間、分、秒フィールドから時間間隔を作成。それぞれがデフォルトでゼロになる
|
時、分、秒フィールドから時刻を作成
|
年、月、日、時、分、秒フィールドから時刻を作成(負の年はBCを意味します)
|
年、月、日、時、分、秒フィールドから時間帯付きの時刻を作成(負の年はBCを意味する)。
|
現在の日付と時刻(現在のトランザクションの開始時)。9.9.5を参照。
|
現在の日付と時刻(現在の文の開始時)。9.9.5を参照。
|
|
現在の日付と時刻(
|
現在の日付と時刻(現在のトランザクションの開始時)。9.9.5を参照。
|
Unixエポック時間(1970-01-01 00:00:00+00からの経過秒数)をtimestamp with time zoneに変換
|
これらの関数に加え、OVERLAPS SQL演算子がサポートされています。
(start1,end1) OVERLAPS (start2,end2) (start1,length1) OVERLAPS (start2,length2)
この式は、2つの時間間隔(その両端で定義されます)が重なる時に真を返します。重ならない場合は偽を返します。
両端は2つの日付、時刻、タイムスタンプとして、もしくは、日付/時刻/タイムスタンプとそれに続く時間間隔として指定できます。
値の組み合わせで指定する場合、開始と終了のいずれを先に記述しても構いません。OVERLAPSは与えられた値のうち、早い方を開始として扱います。
各時間間隔は、start <= time < endという半開区間として見なされます。ただし、startとendが同じ値の場合には単一の時間点となります。
これは、例えば端点のみが共通である2つの時間間隔は、重ならないということを意味します。
SELECT (DATE '2001-02-16', DATE '2001-12-21') OVERLAPS
(DATE '2001-10-30', DATE '2002-10-30');
Result: true
SELECT (DATE '2001-02-16', INTERVAL '100 days') OVERLAPS
(DATE '2001-10-30', DATE '2002-10-30');
Result: false
SELECT (DATE '2001-10-29', DATE '2001-10-30') OVERLAPS
(DATE '2001-10-30', DATE '2001-10-31');
Result: false
SELECT (DATE '2001-10-30', DATE '2001-10-30') OVERLAPS
(DATE '2001-10-30', DATE '2001-10-31');
Result: true
timestampまたはtimestamp with time zoneの値にintervalの値を加える際には(あるいはintervalの値を引く際には)、interval値の月、日、マイクロ秒のフィールドが順に適用されます。
まず、非ゼロの月フィールドが示す日数の分だけtimestampの日付を先に進める、もしくは後に戻し、新しい月の最終日を超えてしまわない限り月内の日付を同じに保ちます。月の最後の日を超えてしまうようなら、その月の最終日が使われます。
(たちえば、3月31日に1ヶ月を加えると4月30日になりますが、3月31日に2ヶ月を加えると5月31日になります。)
次に、日フィールド分だけtimestampの日付を先に進める、もしくは後に戻します。
この両方の処理において、現地時刻は同じに保ちます。
最後に、非ゼロのマイクロ秒フィールドがあれば、そのまま加算、もしくは減算します。
DSTと認識される時間帯におけるtimestamp with time zone値の演算を行う際には、(たとえば)interval '1 day'を加算、もしくは減算することは、interval '24 hours'を加算、もしくは減算するのと同じ結果になるとは限りません。
例えば、セッションの時間帯が America/Denverに設定されている時には以下のようになります。
SELECT timestamp with time zone '2005-04-02 12:00:00-07' + interval '1 day'; Result:2005-04-03 12:00:00-06SELECT timestamp with time zone '2005-04-02 12:00:00-07' + interval '24 hours'; Result:2005-04-03 13:00:00-06
その理由はAmerica/Denver時間帯で2005-04-03 02:00:00に夏時間への変更され、1時間スキップされたためです。
異なる月では日数が異なりますのでageで返されるmonthsフィールドにはあいまいさがあります。
PostgreSQLのやり方は月をまたがる2つの日付の計算において、日付の早いほうの月を使用します。
例えば、age('2004-06-01', '2004-04-30')は4月を使用して1 mon 1 dayを得ます。5月は31日あり、4月は30日のため、もし5月を使用するなら結果は1 mon 2 daysとなるでしょう。
日付とタイムスタンプの引き算は複雑になることがあります。
引き算をする概念的に単純な方法は、それぞれの値を秒数にEXTRACT(EPOCH FROM ...)で変換してから、結果を引き算する方法です。この結果は2つの値の間の秒数になります。
これは各月の日数、時間帯の変更、夏時間の調整に対して調整されるでしょう。
「-」演算子での日付やタイムスタンプの引き算は値の間の(24時間の)日数と時間/分/秒を、同様に調整して返します。
age関数は年、月、日、時間/分/秒をフィールド毎に引き算し、負のフィールドの値を調整します。
以下の問い合わせは上の各方法の違いを説明する例です。
例の結果はtimezone = 'US/Eastern'で生成されました。2つの日付の間には夏時間の変更があります。
SELECT EXTRACT(EPOCH FROM timestamptz '2013-07-01 12:00:00') -
EXTRACT(EPOCH FROM timestamptz '2013-03-01 12:00:00');
Result: 10537200.000000
SELECT (EXTRACT(EPOCH FROM timestamptz '2013-07-01 12:00:00') -
EXTRACT(EPOCH FROM timestamptz '2013-03-01 12:00:00'))
/ 60 / 60 / 24;
Result: 121.9583333333333333
SELECT timestamptz '2013-07-01 12:00:00' - timestamptz '2013-03-01 12:00:00';
Result: 121 days 23:00:00
SELECT age(timestamptz '2013-07-01 12:00:00', timestamptz '2013-03-01 12:00:00');
Result: 4 mons
EXTRACT, date_part #EXTRACT(fieldFROMsource)
extract関数は、日付/時刻の値から年や時などの部分フィールドを抽出します。
sourceはtimestamp、date、time、interval型の値式でなければなりません。
(timestampとtimeは、タイムゾーンの有無に関わらず指定できます。)
fieldはsourceの値からどのフィールドを抽出するかを選択する識別子もしくは文字列です。
すべての入力データ型に対してすべてのフィールドが有効であるとは限りません。
たとえば、1日より小さいフィールドはdateから抽出できませんし、1日以上のフィールドはtimeから抽出できません。
extract関数はnumeric型の値を返します。
以下は有効なフィールド名です。
century
世紀。
interval値の場合、年フィールドを100で割った値
SELECT EXTRACT(CENTURY FROM TIMESTAMP '2000-12-16 12:21:13'); Result:20SELECT EXTRACT(CENTURY FROM TIMESTAMP '2001-02-16 20:38:40'); Result:21SELECT EXTRACT(CENTURY FROM DATE '0001-01-01 AD'); Result:1SELECT EXTRACT(CENTURY FROM DATE '0001-12-31 BC'); Result:-1SELECT EXTRACT(CENTURY FROM INTERVAL '2001 years'); Result:20
day
月内の日(1–31)。
interval値の場合は日数
SELECT EXTRACT(DAY FROM TIMESTAMP '2001-02-16 20:38:40'); Result:16SELECT EXTRACT(DAY FROM INTERVAL '40 days 1 minute'); Result:40
decade年フィールドを10で割ったもの
SELECT EXTRACT(DECADE FROM TIMESTAMP '2001-02-16 20:38:40');
Result: 200
dow
日曜日(0)から土曜日(6)までの曜日
SELECT EXTRACT(DOW FROM TIMESTAMP '2001-02-16 20:38:40');
Result: 5
extract関数の曜日番号はto_char(...,'D')関数のそれとは異なる点に注意してください。
doy年内での通算日数(1–365/366)
SELECT EXTRACT(DOY FROM TIMESTAMP '2001-02-16 20:38:40');
Result: 47
epoch
timestamp with time zone型の値においては、1970-01-01 00:00:00 UTCからの秒数(負の数はその前)。dateとtimestamp型の値においては、時間帯と夏時間を考慮しないローカルタイムの1970-01-01 00:00:00からの秒数。interval型の値ではその時間間隔における合計の秒数。
SELECT EXTRACT(EPOCH FROM TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40.12-08'); Result:982384720.120000SELECT EXTRACT(EPOCH FROM TIMESTAMP '2001-02-16 20:38:40.12'); Result:982355920.120000SELECT EXTRACT(EPOCH FROM INTERVAL '5 days 3 hours'); Result:442800.000000
to_timestampで経過秒数をtimestamp with time zoneに変換することができます。
SELECT to_timestamp(982384720.12);
Result: 2001-02-17 04:38:40.12+00
to_timestampをdateあるいはtimestampの値から取り出したエポックに適用すると、誤解を招く結果が得られるかもしれないことに注意してください。結果は実質的に元の値がUTCで与えられていると見なしますが、実際は違うかもしれません。
hour時間フィールド(TIMESTAMPの場合は0–23、INTERVALの場合は無制限)。
SELECT EXTRACT(HOUR FROM TIMESTAMP '2001-02-16 20:38:40');
Result: 20
isodow
月曜日(1)から日曜日(7)までの曜日
SELECT EXTRACT(ISODOW FROM TIMESTAMP '2001-02-18 20:38:40');
Result: 7
日曜日を除きdowと同一です。
これはISO 8601曜日番号付けに一致します。
isoyearその日付に該当するISO 8601週番号年。
SELECT EXTRACT(ISOYEAR FROM DATE '2006-01-01'); Result:2005SELECT EXTRACT(ISOYEAR FROM DATE '2006-01-02'); Result:2006
すべてのISO 8601週番号年は1月4日を含む週の月曜日から開始されます。従って、1月上旬、または12月下旬でISO年がグレゴリオ年と異なる可能性があります。
より詳細はweekフィールドを参照してください。
julian日付またはタイムスタンプに対応するユリウス日。 ローカル午前零時でないタイムスタンプは、小数値になります。 詳細はB.7を参照してください。
SELECT EXTRACT(JULIAN FROM DATE '2006-01-01'); Result:2453737SELECT EXTRACT(JULIAN FROM TIMESTAMP '2006-01-01 12:00'); Result:2453737.50000000000000000000
microseconds端数部分も含む秒フィールドに、1,000,000を乗じた値。秒の整数部を含むことに注意。
SELECT EXTRACT(MICROSECONDS FROM TIME '17:12:28.5');
Result: 28500000
millennium
千年紀。
interval値の場合、年フィールドを1000で割った値
SELECT EXTRACT(MILLENNIUM FROM TIMESTAMP '2001-02-16 20:38:40'); Result:3SELECT EXTRACT(MILLENNIUM FROM INTERVAL '2001 years'); Result:2
1900年代の年は第2ミレニアムです。第3ミレニアムは2001年1月1日から始まりました。
milliseconds端数部分も含む秒フィールドに、1000を乗た値。秒の整数部を含むことに注意してください。
SELECT EXTRACT(MILLISECONDS FROM TIME '17:12:28.5');
Result: 28500.000
minute分フィールド (0–59)
SELECT EXTRACT(MINUTE FROM TIMESTAMP '2001-02-16 20:38:40');
Result: 38
month
年内の月の番号(1~12)。interval値の場合、月数を12で割った余り(0~11)
SELECT EXTRACT(MONTH FROM TIMESTAMP '2001-02-16 20:38:40'); Result:2SELECT EXTRACT(MONTH FROM INTERVAL '2 years 3 months'); Result:3SELECT EXTRACT(MONTH FROM INTERVAL '2 years 13 months'); Result:1
quarterその日付が含まれる年の四半期(1–4)
SELECT EXTRACT(QUARTER FROM TIMESTAMP '2001-02-16 20:38:40');
Result: 1
second端数を含んだ秒フィールド
SELECT EXTRACT(SECOND FROM TIMESTAMP '2001-02-16 20:38:40'); Result:40.000000SELECT EXTRACT(SECOND FROM TIME '17:12:28.5'); Result:28.500000
timezone秒単位のUTCからの時間帯オフセット。正の値はUTCより東の時間帯に対応し、負の値はUTCより西の時間帯に対応。 (技術的に言えば、PostgreSQLはうるう秒を制御しないためUTCを使用していない。)
timezone_hour時間帯オフセットの時の成分。
timezone_minute時間帯オフセットの分の成分。
weekISO 8601週番号。 定義ではISO週は月曜日から始まり、その年の1月4日を含む週をその年の第1週としています。 つまり、年の最初の木曜日がある週がその年の第1週となります。
ISO週番号システムでは、1月の早い日にちは前年の第52週もしくは第53週となることがあり、12月の遅い日にちには次年の最初の週の一部となることがあります。
例えば、2005-01-01は2004年の第53週であり、2006-01-01は2005年の第52週の一部です、一方2012-12-31は2013年の第1週の一部となります。
整合性のある結果を得るため、isoyearフィールドとweekを併用することを推奨します。
SELECT EXTRACT(WEEK FROM TIMESTAMP '2001-02-16 20:38:40');
Result: 7
year
年フィールド。AD零年が存在しないことは忘れないでください。このためADの年からBCの年を減ずる時には注意が必要です。
SELECT EXTRACT(YEAR FROM TIMESTAMP '2001-02-16 20:38:40');
Result: 2001
interval値を処理する場合、extract関数は、interval出力関数で使用される解釈と一致するフィールド値を生成します。
これは、非正規化されたINTERVALでの表示から始めた場合、驚くべき結果を生じる可能性があります。
例えば次のようになります。
SELECT INTERVAL '80 minutes'; Result:01:20:00SELECT EXTRACT(MINUTES FROM INTERVAL '80 minutes'); Result:20
入力値が+/-無限大の場合、extractは単調増加するフィールド(epoch、julian、year、isoyear、decade、century、millennium)に対し、+/-無限大を返します。
その他のフィールドに対してはNULLが返されます。
PostgreSQLの9.6より前のバージョンでは、入力が無限大のすべての場合に対してゼロを返していました。
extract関数は主に演算処理を意図しています。
日付/時刻の値を表示する目的での書式については9.8を参照してください。
date_part関数は伝統的なIngres上で設計されたもので、標準SQLのextract関数と等価です。
date_part('field', source)
ここでfieldパラメータが名前ではなく文字列値である必要があることに注意してください。
date_partで有効なフィールド名はextractと同じです。
歴史的な理由により、date_part関数はdouble precision型の結果を返します。
場合によってはこれによって精度が失われることがあります。
extractを代わりに使うことをお勧めします。
SELECT date_part('day', TIMESTAMP '2001-02-16 20:38:40');
Result: 16
SELECT date_part('hour', INTERVAL '4 hours 3 minutes');
Result: 4
date_trunc #
date_trunc関数は概念的に数値に対するtrunc関数と類似しています。
date_trunc(field,source[,time_zone])
sourceは、データ型timestamp、timestamp with time zoneもしくはintervalの値式です。
(date型とtime型の値はそれぞれ自動的にtimestampもしくはintervalにキャストされます。)
fieldは、入力値の値をどの精度で切り捨てるかを選択します。
同様に戻り値はtimestamp、timestamp with time zoneもしくはinterval型で、指定した精度より下のすべてのフィールドがゼロに設定(日と月については1に設定)されます。
fieldの有効値には次のものがあります。
microseconds |
milliseconds |
second |
minute |
hour |
day |
week |
month |
quarter |
year |
decade |
century |
millennium |
入力値がtimestamp with time zone型の値なら、特定の時間帯を考慮して切り捨てが行われます。たとえば、日を切り捨てると値はその時間帯での真夜中になります。
デフォルトでは切り捨ては現在のTimeZoneの設定に従いますが、別の時間帯を指定することができるようにオプションのtime_zone引数が提供されています。
時間帯名は8.5.3に記述されている方法で指定できます。
timestamp without time zoneあるいはintervalの入力を処理している間は時間帯は指定できません。
これらは額面通りの値で扱われます。
例(現地タイムゾーンはAmerica/New_Yorkと仮定します):
SELECT date_trunc('hour', TIMESTAMP '2001-02-16 20:38:40');
Result: 2001-02-16 20:00:00
SELECT date_trunc('year', TIMESTAMP '2001-02-16 20:38:40');
Result: 2001-01-01 00:00:00
SELECT date_trunc('day', TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40+00');
Result: 2001-02-16 00:00:00-05
SELECT date_trunc('day', TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40+00', 'Australia/Sydney');
Result: 2001-02-16 08:00:00-05
SELECT date_trunc('hour', INTERVAL '3 days 02:47:33');
Result: 3 days 02:00:00
date_bin #
関数date_binは、指定した原点に揃えて入力のタイムスタンプを指定した時間間隔(stride)に「分類」します。
date_bin(stride,source,origin)
sourceはtimestampあるいはtimestamp with time zone型の値式です。
(date型の値はtimestampに自動キャストされます。)
strideはinterval型の値式です。
戻り値は同様に、timestampあるいはtimestamp with time zone型で、sourceが置かれた箱の開始位置に印を付けています。
例を示します。
SELECT date_bin('15 minutes', TIMESTAMP '2020-02-11 15:44:17', TIMESTAMP '2001-01-01');
Result: 2020-02-11 15:30:00
SELECT date_bin('15 minutes', TIMESTAMP '2020-02-11 15:44:17', TIMESTAMP '2001-01-01 00:02:30');
Result: 2020-02-11 15:32:30
完全な単位(1分、1時間など)の場合は、これは類似のdate_truncの呼び出しと同じ結果を与えます。
違いは、date_binは任意の間隔へと切り捨てられることです。
stride間隔はゼロより大きくなければならず、かつ月単位あるいはそれよりも大きくてはいけません。
AT TIME ZONE #
AT TIME ZONE構文を使用することにより、time stamp without time zoneからtime stamp with time zoneへ、あるいはtime with time zoneの値を異なる時間帯に変換することができます。
表 9.34にその種類を示します。
表9.34 AT TIME ZONEの種類
演算子 説明 例 |
|---|
与えられた時間帯なしタイムスタンプを指定された時間帯にあるとして時間帯ありタイムスタンプに変換します。
|
与えられた時間帯付き時刻を、時刻がその時間帯にあるものとして時間帯なしタイムスタンプに変換します。
|
与えられた時刻with time zoneを新しい時間帯に変換します。 判断するためのデータがないので、現在の有効なUTCオフセットを目的の時間帯のために使用します。
|
これらの式では、設定する時間帯zoneは、('America/Los_Angeles'のような)テキスト値、または(INTERVAL '-08:00'のような)時間間隔で指定することができます。
テキストの場合、8.5.3に示した方法で時間帯名称を指定することができます。
時間間隔を使うのはUTCからの固定のオフセットを持つ時間帯でのみ有用なので、一般的に非常に有用であるとは言えません。
以下に例を示します(現在の時間帯(TimeZone)をAmerica/Los_Angelesと想定しています)。
SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'America/Denver'; Result:2001-02-16 19:38:40-08SELECT TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40-05' AT TIME ZONE 'America/Denver'; Result:2001-02-16 18:38:40SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'Asia/Tokyo' AT TIME ZONE 'America/Chicago'; Result:2001-02-16 05:38:40
最初の例は、時間帯のない値に時間帯を追加し、現在のTimeZone設定を使ってその値を表示します。
2番目の例は、time stamp with time zone値を指定した時間帯に変換し、その値をwithout a time zoneで返しています。
これは、TimeZone設定とは異なる値の格納と表示を可能にします。
3番目の例は、東京時間をシカゴ時間に変換します。
関数は、SQL準拠の構文timezone(zone, timestamp)と等価です。
timestamp AT TIME ZONE zone
PostgreSQLは、現在の日付時刻に関した値を返す多くの関数を提供します。 これらの標準SQL関数はすべて、現在のトランザクションの開始時刻に基づいた値を返します。
CURRENT_DATE CURRENT_TIME CURRENT_TIMESTAMP CURRENT_TIME(precision) CURRENT_TIMESTAMP(precision) LOCALTIME LOCALTIMESTAMP LOCALTIME(precision) LOCALTIMESTAMP(precision)
CURRENT_TIMEおよびCURRENT_TIMESTAMP関数では、時間帯を伴う値を扱います。一方、LOCALTIMEおよびLOCALTIMESTAMP関数では、時間帯を伴わない値を扱います。
CURRENT_TIME、CURRENT_TIMESTAMP、LOCALTIME、およびLOCALTIMESTAMP関数では、精度のパラメータをオプションで取ることができ、それに合わせて秒フィールドの端数桁を丸める結果をもたらします。
精度のパラメータがない場合、結果は使用可能な最大精度で出力されます。
例:
SELECT CURRENT_TIME; Result:14:39:53.662522-05SELECT CURRENT_DATE; Result:2019-12-23SELECT CURRENT_TIMESTAMP; Result:2019-12-23 14:39:53.662522-05SELECT CURRENT_TIMESTAMP(2); Result:2019-12-23 14:39:53.66-05SELECT LOCALTIMESTAMP; Result:2019-12-23 14:39:53.662522
これらの関数は現在のトランザクションの開始時刻を返すため、その値はトランザクションが実行されている間は変化しません。 これは仕様であると考えられており、その意図は、単一のトランザクションが一貫性のある「現在」時刻の概念を持ち、同一トランザクション内の複数の変更が同一のタイムスタンプを持つようにすることにあります。
他のデータベースシステムでは、これらの値をより頻繁に増加させることがあります。
PostgreSQLはまた、関数を呼び出した時の実際の現在時刻や現在の文の開始時刻を返す関数も提供します。 非標準SQLの時間関数の全一覧を以下に示します。
transaction_timestamp() statement_timestamp() clock_timestamp() timeofday() now()
transaction_timestamp()はCURRENT_TIMESTAMPと等価ですが、明確に何を返すかを反映する名前になっています。
statement_timestamp()は現在の文の実行開始時刻を返すものです(より具体的にいうと、直前のコマンドメッセージをクライアントから受け取った時刻です)。
statement_timestamp()およびtransaction_timestamp()はトランザクションの最初のコマンドでは同じ値を返しますが、その後に引き続くコマンドでは異なる可能性があります。
clock_timestamp()は実際の現在時刻を返しますので、その値は単一のSQLコマンドであっても異なります。
timeofday()はPostgreSQLの歴史的な関数です。
clock_timestamp()同様、実際の現在時刻を返しますが、timestamp with time zone型の値ではなく、整形されたtext文字列を返します。now()はtransaction_timestamp()と同じもので、伝統的なPostgreSQL関数です。
すべての日付/時刻型はまた、特殊なリテラル値 nowを受け付け、これは現在の日付と時刻(ここでも、トランザクションの開始時刻として解釈されます)を表します。
したがって、下記の3つの実行結果は全て同じものとなります。
SELECT CURRENT_TIMESTAMP; SELECT now(); SELECT TIMESTAMP 'now'; -- but see tip below
たとえばテーブルの列にDEFAULT句を指定するのに、後から評価される値を指定する際に3番目の形式は使わないでください。
システムはnowという定数を解析すると、すぐにそれをtimestampに変換するので、デフォルト値が必要が時には、テーブルが作成された時刻が使われます。
最初の2つの形式は関数呼び出しなので、デフォルト値が使用されるまで評価されません。
ですから、これらの関数は列の挿入時間をデフォルトとする、望ましい振舞いをします。
(8.5.1.4も見てください。)
以下の関数は、サーバプロセスの実行を遅延させるために使用可能です。
pg_sleep (double precision) pg_sleep_for (interval) pg_sleep_until (timestamp with time zone)
pg_sleepは、指定された秒数が経過するまで、現在のセッションのプロセスを休止させます。
pg_sleep_forはintervalでより長い休止時間を指定する便利な関数です。
pg_sleep_untilは特定の起床時刻が望まれる場合に便利な関数です。
以下に例を示します。
SELECT pg_sleep(1.5);
SELECT pg_sleep_for('5 minutes');
SELECT pg_sleep_until('tomorrow 03:00');
休止時間の有効な分解能はプラットフォームに依存します。0.01秒が一般的な値です。
休止による遅延は最短で指定した時間と同じになります。
サーバの負荷などが要因となり、より長くなる可能性があります。
特に、pg_sleep_untilは指定した時刻ちょうどに起床する保証はありませんが、それより早く起床することはありません。
pg_sleepまたはその亜種を呼び出す時、セッションが必要以上のロックを保持していないことを確実にしてください。
さもないと、他のセッションが休止中のプロセスを待機しなければならないかもしれません。そのためシステム全体の速度が低下することになるかもしれません。