次のことができるようです。
SET DATESTYLE = 'YMD';
SELECT
テーブルから出る前に。ただし、これは、ファイルからの日付だけでなく、すべての日付の解釈に影響します。他の場所で明確なISO日付を一貫して使用している場合は問題ありませんが、(たとえば)同じクエリで「D / M/Y」日付リテラルも受け入れる必要がある場合は問題になる可能性があります。
これはGreenPlumに固有であり、以下に示すように、CREATE EXTERNAL TABLE
SQL標準の外部データラッパーには適用されません。SQL/MED
私が驚いたのは、PostgreSQL本体(このCREATE EXTERNAL TABLE
機能がない)は、に関係なく、常にISOスタイルYYYY-MM-DD
とYYYYMMDD
日付を受け入れることですDATESTYLE
。観察:
regress=> SELECT '20121229'::date, '2012-12-29'::date, current_setting('DateStyle');
date | date | current_setting
------------+------------+-----------------
2012-12-29 | 2012-12-29 | ISO, MDY
(1 row)
regress=> SET DateStyle = 'DMY';
SET
regress=> SELECT '20121229'::date, '2012-12-29'::date, current_setting('DateStyle');
date | date | current_setting
------------+------------+-----------------
2012-12-29 | 2012-12-29 | ISO, DMY
(1 row)
...したがって、GreenPlumが同じように動作する場合YYYYMMDD
、入力ファイルからこれらの日付を正しく読み取るために何もする必要はありません。
PostgreSQLfile_fdw
SQL/MED
の外部データラッパーでどのように機能するかを次に示します。
CREATE EXTENSION file_fdw;
COPY (SELECT '20121229', '2012-12-29') TO '/tmp/dates.csv' CSV;
SET DateStyle = 'DMY';
CREATE SERVER csvtest FOREIGN DATA WRAPPER file_fdw;
CREATE FOREIGN TABLE csvtest (
date1 date,
date2 date
) SERVER csvtest OPTIONS ( filename '/tmp/dates.csv', format 'csv' );
SELECT * FROM csvtest ;
date1 | date2
------------+------------
2012-12-29 | 2012-12-29
(1 row)
CSVファイルの内容は次のとおりです。
20121229,2012-12-29
したがって、Pgは、日付スタイルに関係なく、CSVのISO日付を常に受け入れることがわかります。
GreenPlumが機能しない場合は、バグを報告してください。作成後に外部テーブルの読み取り方法を変更するというアイデアDateStyle
はおかしいです。