Einzelner Datentyp für ungenaue Datumswerte gemäß ISO 8601

Wie kann ich Datums- und Zeitwerte mit reduzierter Genauigkeit in einem PostgreSQL-Typ speichern und sie als Datums- und / oder Zeitwerte verhalten lassen ?

ISO 8601 ermöglicht Datumswerte mit reduzierter Genauigkeit. '1964', '1964-05', '1964-05-02' sind alle gültigen Darstellungen eines Wertes mit zunehmender Genauigkeit. Die Python-Datetime-Typen ermöglichen auf diese Weise auch Werte mit reduzierter Genauigkeit.

Native PostgreSQL-Zeittypen erlauben keine reduzierte Genauigkeit

Im nativen Datumstyp muss jedes Element eines Datums vorhanden sein, sonst wird der Wert abgelehnt. Das Einstellen der Elemente unterhalb der gewünschten Genauigkeitsstufe auf '00' schlägt ebenfalls fehl.

=> SELECT CAST('1964-05-02' AS DATE);
    date    
------------
 1964-05-02
(1 row)

=> SELECT CAST('1964-05' AS DATE);
ERROR:  invalid input syntax for type date: "1964-05"
LINE 1: SELECT CAST('1964-05' AS DATE);
                    ^
=> SELECT CAST('1964' AS DATE);
ERROR:  invalid input syntax for type date: "1964"
LINE 1: SELECT CAST('1964' AS DATE);
                    ^
=> SELECT CAST('1964-00-00' AS DATE);
ERROR:  date/time field value out of range: "1964-00-00"
LINE 1: SELECT CAST('1964-00-00' AS DATE);
                    ^
HINT:  Perhaps you need a different "datestyle" setting.

Erwartetes Verhalten für einen Datums- und / oder Zeittyp mit reduzierter Genauigkeit

Gibt es eine einfache Standardmethode, um die Eingabe von ISO 8601-Datumswerten mit reduzierter Genauigkeit in einen PostgreSQL-Datums- und / oder Zeittyp zu unterstützen?

Es ist möglich, einen Typ dafür zu erstellen, aber ich weiß nicht wie. Natürlich müssen die Werte im Bereich überprüft werden, Zeitzonen behandelt und alle anderen nützlichen Funktionen der integrierten Typen sinnvoll mit anderen Zeitwerten verglichen werden.

Was ich erwarte ist, dass, genau wie der Wert '1964-05-02' sich auf das gesamte Intervall zwischen 00:00:00 an diesem Tag bis 00:00:00 am nächsten Tag bezieht, ein Wert mit reduzierter Genauigkeit einfach a darstellen würde größeres Intervall: "1962-05" bezieht sich auf das gesamte Intervall zwischen 00:00:00 Anfang Mai 1962 und 00:00:00 am ersten Juni 1962.

Ein Beispiel für das, was ich sehen möchte:

=> SELECT CAST('1964-05-02 00:00' AS TIMESTAMP) = CAST('1964-05-02 00:00:00' AS TIMESTAMP);
 ?column? 
----------
 t
(1 row)

=> SELECT CAST('1964-05' AS TIMESTAMP) = CAST('1964-05-02' AS TIMESTAMP);
 ?column? 
----------
 t
(1 row)

Derzeit verhält sich Ersteres wie oben; Letzterer beschwert sich über "ungültige Eingabesyntax für Typ Zeitstempel". Meines Erachtens handelt es sich bei beiden Fällen um Werte mit reduzierter Genauigkeit, die sich im Vergleich zu Werten mit feinerer Genauigkeit vernünftig verhalten.

Die Bedeutung von 1964-05in ISO 8601 umfasst die genaueren Werte 1964-05-02und 1964-05-02 18:27und 1964-05-23. Also sollten diese alle gleich vergleichen.

Ich habe in der Vergangenheit CHAR und VARCHAR verwendet und die fehlenden Teile durch Fragezeichen oder Bindestriche ersetzt. Fragezeichen bedeuten "nicht bekannt" und Bindestriche bedeuten "nicht zutreffend". Dies erwies sich für die Benutzer (Sekretäre und Rechtsanwaltsanwärter in komplexen Rechtsstreitigkeiten) als intuitiv genug, für die Anwälte als flexibel genug und sinnvoll sortiert.

"1964------"
"1964-??-??"
"1964-05---"
"1964-05-??"
"1964-05-02"
"1964-06---"
"1964-06-??"

Schließen Sie Ihre Deklaration und CHECK-Einschränkungen in CREATE DOMAIN oder CREATE TYPE ein, um die Wartung zu vereinfachen. CREATE DOMAIN erfordert keine zusätzliche Codierung. CREATE TYPE erfordert Support-Funktionen, die in einer einfachen Sprache geschrieben sind.

Nein, die Intervall - Typ unterstützt reduzierter Genauigkeit , aber keiner der anderen Datum / Zeit - Typen tun.

Mit Postgres können Sie Ihre eigenen rollen, create typeaber leider können dem Typ keine Einschränkungen hinzugefügt werden, was die Nützlichkeit in diesem Szenario einschränkt. Das Beste, was ich mir einfallen lassen kann, ist, dass Sie die Überprüfungsbeschränkungen für jedes Feld wiederholen, in dem der fuzzyTyp verwendet wird:

create type preciseness as enum('day', 'month', 'year');
create type fuzzytimestamptz as (ts timestamptz, p preciseness);
create table t( id serial primary key,
                fuzzy fuzzytimestamptz
                    check( (fuzzy).ts is not null 
                           or ((fuzzy).ts is null and (fuzzy).p is not null) ),
                    check((fuzzy).ts=date_trunc('year', (fuzzy).ts) or (fuzzy).p<'year'),
                    check((fuzzy).ts=date_trunc('month', (fuzzy).ts) or (fuzzy).p<'month'),
                    check((fuzzy).ts=date_trunc('day', (fuzzy).ts) or (fuzzy).p<'day') );

insert into t(fuzzy) values (row(date_trunc('year', current_timestamp), 'year'));
insert into t(fuzzy) values (row(date_trunc('month', current_timestamp), 'month'));
insert into t(fuzzy) values (row(date_trunc('day', current_timestamp), 'day'));

select * from t;

 id |              fuzzy
----+----------------------------------
  1 | ("2011-01-01 00:00:00+00",year)
  2 | ("2011-09-01 00:00:00+01",month)
  3 | ("2011-09-23 00:00:00+01",day)

--edit - ein Beispiel für einen Gleichheitsoperator:

create function fuzzytimestamptz_equality(fuzzytimestamptz, fuzzytimestamptz)
                returns boolean language plpgsql immutable as $$
begin
  return ($1.ts, $1.ts+coalesce('1 '||$1.p, '0')::interval)
         overlaps ($2.ts, $2.ts+coalesce('1 '||$2.p, '0')::interval);
end;$$;
--
create operator = ( procedure=fuzzytimestamptz_equality, 
                    leftarg=fuzzytimestamptz, 
                    rightarg=fuzzytimestamptz );

Beispielabfrage:

select *, fuzzy=row(statement_timestamp(), null)::fuzzytimestamptz as equals_now,
          fuzzy=row(statement_timestamp()+'1 day'::interval, null)::fuzzytimestamptz as equals_tomorrow,
          fuzzy=row(date_trunc('month', statement_timestamp()), 'month')::fuzzytimestamptz as equals_fuzzymonth,
          fuzzy=row(date_trunc('month', statement_timestamp()+'1 month'::interval), 'month')::fuzzytimestamptz as equals_fuzzynextmonth
from t;
 id |               fuzzy                | equals_now | equals_tomorrow | equals_fuzzymonth | equals_fuzzynextmonth
----+------------------------------------+------------+-----------------+-------------------+-----------------------
  1 | ("2011-01-01 00:00:00+00",year)    | t          | t               | t                 | t
  2 | ("2011-09-01 00:00:00+01",month)   | t          | t               | t                 | f
  3 | ("2011-09-24 00:00:00+01",day)     | t          | f               | t                 | f
  4 | ("2011-09-24 11:45:23.810589+01",) | f          | f               | t                 | f