Ich wollte es nur erwähnen, weil ich immer wieder Leute treffe, die denken das der JOIN Operator was “ganz neues” wäre.
Einige verbreitete Datenbanksysteme haben das auch sehr lange nicht unterstützt (Oracle, SQL Server). Und in der Oracle Community gibt es noch einige Benutzer die sich immer noch weigern das zu verwenden weil es ganz am Anfang als Oracle das vor rund 15 Jahren eingeführt hat ein paar Bugs mit der Syntax gab.
Leider muss ich auch Postgres einen kleinen Vorwurf machen, weil in der Dokumentation praktisch alle Beispiele implizite joins verwenden und nicht den expliziten JOIN Operator.
Die impliziten joins haben das Problem, dass sie leicht in einem ungewollten cross join resultieren weil es kein Syntaxfehler ist die join Bedingung zu vergessen. Deswegen empfehle ich immer wo es nur geht, den “modernen” JOIN Operator zu verwenden.
Fri Oct 05 2018 19:52:14 GMT+0200 (CEST) <<< ist das Format von date_time in meiner Tabelle
Frage: ist es möglich dieses Format zu wandeln damit ich mit TT.MM.JJJJ alles vom 05.10.2018 auslesen kann, oder geht das nur mit der between … and Bedingung
vermutlich hast da also ein timestamptz drin stehen, select spalte::date liefert dir das reine Datum, where spalte::date=‘2018-10-05’ könntest Du es prüfen, oder via to_char(spalte, ‘tt.mm.yyyy’) auf Dein Format bringen.
die Idee ist nicht von mir, die Datenbank wurde mir so zu Verfügung gestellt.
Alternativ gibt es noch eine andere Tabelle mit einer “beg_timestamp” Spalte aber da komm ich auch nicht weiter.
Einmal nur möchte ich es erleben, dass diejenigen die solche schwachsinnigen “Design” Entscheidungen treffen auch damit bestraft werden sie zu benützen…
Aber nachdem Du nunmal damit leben musst:
Du kannst mit to_date() oder to_timestamp() einen String in ein Datum verwandeln, z.B.:
(Statt dem String musst Du halt Deine Spalte übergeben)
Die “bigint” Spalte speichert vermutlich ein “Unix epoch” - das ist im Prinzip die Anzahl der Sekunden seit dem 1.1.1970. Das kannst Du auch in einen vernünftige Timestamp Wert umwandeln:
to_timestamp(1538761934::bigint)
liefert auch den 05.10.2018 19:52:14
Das kann man dann mittels ::date wieder zu einem Datum verwandeln:
der der das Verbrochen hat meldet sich leider nicht mehr!!
das mit dem Datum bring ich nicht auf die Reihe, vielleicht haben wir uns falsch verstanden.
zur Vereinfachung meiner Selects würde ich gerne mit einen Datum in dieser Art arbeiten tt.mm.jjjj ich hab aber in meinen Tabellen das Datum in Form von date_time= Fri May 11 2018 20:01:41 GMT+0200 (CEST) oder als beg_timestamp=1520373303652
hab noch eine andere Frage, wie verhält sich das mit der “id” die die Datenbank ja selbst vergibt, wenn ich Neue Daten aus einer CSV Datei mit copy in die bestehende Tabelle einfügen möchte?
ERROR: FEHLER: NULL-Wert in Spalte »shooters_id« verletzt Not-Null-Constraint
einfach beim COPY angeben, daß für diese Spalte keine Daten kommen:
test=*# create table bla (id serial primary key, val int);
CREATE TABLE
test=*# copy bla(val) from stdin;
Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself, or an EOF signal.
>> 10
>> 23
>> 23
>> 12
>> 22
>> \.
COPY 5
test=*# select * from bla;
id | val
----+-----
1 | 10
2 | 23
3 | 23
4 | 12
5 | 22
(5 rows)
test=*#
ERROR: FEHLER: fehlende Daten für Spalte »shooters_id«
. mag er nicht
wenn ich dann doch eine Zahl eingebe die deutlich größer ist als die letzte vergebene meint er die existiert schon