Ich muss Daten ohne Zeitzoneninformationen darin importieren (aber ich kenne die genaue Zeitzone der Daten, die ich importieren möchte), aber ich brauche das Format timestamp with time zone in der Datenbank . Sobald ich es importiere und den Zeitstempeldatentyp auf timestamp with time zone setze, nimmt Postgres automatisch an, dass die Daten in der Tabelle aus meiner Zeitzone stammen und weise mir meine Zeitzone zu. Leider sind die Daten, die ich importieren möchte, nicht von meinem Zeitrahmen, also funktioniert das nicht.
Die Datenbank enthält auch Daten mit unterschiedlichen Zeitzonen. Die Zeitzone innerhalb einer Tabelle ist jedoch immer gleich.
Nun könnte ich die Zeitzone der Datenbank auf die Zeitzone der Daten einstellen, die ich importieren möchte, bevor ich die Daten importiere (mit dem Befehl SET time zone ) und sie nach dem Import wieder in meine Zeitzone ändern, und ich bin mir ziemlich sicher, dass bereits gespeicherte Daten nicht von der Zeitzonenänderung der Datenbank betroffen sind. Aber das scheint ein ziemlich dreckiger Ansatz zu sein und kann später Probleme verursachen.
Ich frage mich, ob es eine elegantere Möglichkeit gibt, die Zeitzone für den Import anzugeben, ohne die Zeitzonendaten in den Daten selbst zu haben?
Ich habe auch keine Möglichkeit gefunden, Zeitzoneninformationen nach dem Import zu bearbeiten. Gibt es eine Möglichkeit, nicht zu konvertieren, sondern einfach die Zeitzone für eine ganze Tabelle zu bearbeiten, unter der Annahme, dass die gesamte Tabelle denselben Zeitzonen-Offset hat (dh wenn bei der Dateneingabe / -import ein falscher zugewiesen wurde)?
Bearbeiten:
Ich habe es geschafft, beim Import eine Zeitzone anzugeben, der ganze Befehl lautet:
Die Daten werden dann mit der Sitzungszeitzone importiert. Ich nehme an, dies hat keine Auswirkungen auf andere Abfragen in der Datenbank zur gleichen Zeit von anderen Verbindungen?
Edit 2:
Ich habe später herausgefunden, wie man die Zeitzone einer Tabelle ändert:
PostgreSQL Zeitzonenverschiebung aktualisieren
Ich nehme an, es ist eleganter, die Zeitzone der Tabelle nach dem Import zu ändern und dann die Sitzung zu verwenden, um die lokale Zeitzone temporär zu ändern. Angenommen, die gesamte Tabelle hat natürlich die gleiche Zeitzone.
Also wäre der Code jetzt etwas in der Richtung von:
%Vor%Es ist viel viel effizienter, die Zeitzone für Ihre Importsitzung festzulegen als die Werte später zu aktualisieren.
Ich habe den Eindruck, dass Sie die Zeitzone als eine Einstellung betrachten, die für ansonsten unveränderte Werte in den Tabellen gilt. Aber so ist es überhaupt nicht. Stellen Sie es sich als Eingabe / Ausgabe-Modifikator vor. Aktuelle timestamp -Werte (mit oder ohne Zeitzone) werden immer intern als UTC-Zeitstempel gespeichert (Anzahl der Sekunden seit '2000-01-01 00:00' ). Viel mehr Details:
Die UPDATE in Ihrem zweiten Beispiel verdoppelt die Größe der Tabelle, da jede einzelne Zeile ungültig gemacht und eine neue Version hinzugefügt wird (so funktioniert UPDATE mit MVCC in Postgres). Zusätzlich zu der teuren Operation muss VACUUM später mehr Arbeit leisten, um den Tabellen-Bloat zu bereinigen. Sehr ineffektiv.
Es ist vollkommen sicher bis SET der lokalen Zeitzone für die Sitzung. Dies wirkt sich nicht auf gleichzeitige Vorgänge aus. Btw.,% Co_de% ist identisch mit plain SET SESSION , da SET sowieso die Standardeinstellung ist.
Wenn Sie absolut sicher sein möchten, können Sie die Einstellung auf die aktuelle Transaktion mit SESSION beschränken. Ich zitiere das Handbuch hier
Die Effekte von
SET LOCALdauern nur bis zum Ende des aktuellen Transaktion, ob verpflichtet oder nicht. Ein Sonderfall istSET LOCALgefolgt nachSETinnerhalb einer einzelnen Transaktion: DerSET LOCAL-Wert wird sein gesehen bis zum Ende der Transaktion, aber danach (wenn die Transaktion ist festgeschrieben) Der WertSET LOCALwird wirksam.
Zusammengefügt:
%Vor%Überprüfen Sie:
%Vor%Tags und Links datetime postgresql timezone timestamp bulk-load