Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Datumsformat psql
30 views
Skip to first unread message
Marc Santhoff
Jun 23, 2012, 1:59:20 PM6/23/12
to
Tag allerseits,
ich suche und probiere mir hier gerade einen Wolf, komme aber nicht
zurecht:
In welchem Format gebe ich denn mittels psql Datumswerte ein, so daß ein
INSERT auch funktioniert?
Ich habe schon die verschiedensten Varianten durch, aber nix wird
akzeptiert, immer nur Sytaxfehler ...
RTFM zu psql (bis auf die man page) ist auch gern genommen.
Gruß,
Marc
ich suche und probiere mir hier gerade einen Wolf, komme aber nicht
zurecht:
In welchem Format gebe ich denn mittels psql Datumswerte ein, so daß ein
INSERT auch funktioniert?
Ich habe schon die verschiedensten Varianten durch, aber nix wird
akzeptiert, immer nur Sytaxfehler ...
RTFM zu psql (bis auf die man page) ist auch gern genommen.
Gruß,
Marc
Armin Saul
Jun 23, 2012, 2:20:52 PM6/23/12
to
CREATE DATABASE
postgres=# \c kannwech
psql (8.4.12)
SSL-Verbindung (Verschlüsselungsmethode: DHE-RSA-AES256-SHA, Bits: 256)
Sie sind jetzt verbunden mit der Datenbank »kannwech«.
kannwech=# create table beispiel ("id" serial, "zeitstempel" date);
HINWEIS: CREATE TABLE erstellt implizit eine Sequenz »beispiel_id_seq«
für die »serial«-Spalte »beispiel.id«
CREATE TABLE
kannwech=# insert into beispiel (zeitstempel) values ('2012-06-23');
INSERT 0 1
kannwech=# select * from beispiel;
id | zeitstempel
----+-------------
1 | 2012-06-23
(1 Zeile)
kannwech=#
Marc Santhoff
Jun 23, 2012, 2:42:36 PM6/23/12
to
Am Sat, 23 Jun 2012 20:20:52 +0200 schrieb Armin Saul:
> Am 23.06.2012 19:59, schrieb Marc Santhoff:
>> In welchem Format gebe ich denn mittels psql Datumswerte ein, so daß
>> ein INSERT auch funktioniert?
> Am 23.06.2012 19:59, schrieb Marc Santhoff:
>> In welchem Format gebe ich denn mittels psql Datumswerte ein, so daß
>> ein INSERT auch funktioniert?
> kannwech=# insert into beispiel (zeitstempel) values ('2012-06-23');
> INSERT 0 1
>
> kannwech=# select * from beispiel;
> id | zeitstempel
> ----+-------------
> 1 | 2012-06-23
> (1 Zeile)
Urgs, *einfache* Quotes, grummel, die waren mir grade nicht
> INSERT 0 1
>
> kannwech=# select * from beispiel;
> id | zeitstempel
> ----+-------------
> 1 | 2012-06-23
> (1 Zeile)
eingefallen ... :P
Alles versucht, doppelte, ohne, cast'en, ... autsch.
Jetzt fehlt mir nur noch eine funktionierende, sinnvolle Einstellung für
das lokale Datenformat:
<snip>
psql:/home/marc/.psqlrc:12: ERROR: syntax error at or near "german"
ZEILE 1: set datestyle german, dmy
</snip>
So funktioniert's jedenfalls nicht wirklich.
Danke, jetzt kann ich wenigsten überhaupt was eingeben. ;)
Marc
Siegfried Schmidt
Jun 23, 2012, 3:10:10 PM6/23/12
to
Marc Santhoff schrieb:
> In welchem Format gebe ich denn mittels psql Datumswerte ein, so daÃ
> ein INSERT auch funktioniert?
Standardmässig in dem Format, welches du bei der Erstellung der Datenbank
in der lc_time locale festgelegt hast.
Den aktuellen Stand kannst du mit 'show datestyle;" abfragen und mit 'set
datestyle <style>;' nach Belieben ändern.
Willst du ein deutsches Datum einfügen, pack vor den Insert ein 'set
datestyle german;'.
Der Abschnitt 8.5 und der gesamte Anhang B des Manuals beschäftigt sich
mit diesem Gebiet.
Siegfried
> In welchem Format gebe ich denn mittels psql Datumswerte ein, so daÃ
> ein INSERT auch funktioniert?
Standardmässig in dem Format, welches du bei der Erstellung der Datenbank
in der lc_time locale festgelegt hast.
Den aktuellen Stand kannst du mit 'show datestyle;" abfragen und mit 'set
datestyle <style>;' nach Belieben ändern.
Willst du ein deutsches Datum einfügen, pack vor den Insert ein 'set
datestyle german;'.
Der Abschnitt 8.5 und der gesamte Anhang B des Manuals beschäftigt sich
mit diesem Gebiet.
Siegfried
Marc Santhoff
Jun 23, 2012, 3:21:38 PM6/23/12
to
Am Sat, 23 Jun 2012 19:10:10 +0000 schrieb Siegfried Schmidt:
> Marc Santhoff schrieb:
>
>> In welchem Format gebe ich denn mittels psql Datumswerte ein, so daß
> Marc Santhoff schrieb:
>
>> ein INSERT auch funktioniert?
>
> Standardmässig in dem Format, welches du bei der Erstellung der
> Datenbank in der lc_time locale festgelegt hast.
>
> Den aktuellen Stand kannst du mit 'show datestyle;" abfragen und mit
> 'set datestyle <style>;' nach Belieben ändern.
>
> Willst du ein deutsches Datum einfügen, pack vor den Insert ein 'set
> datestyle german;'.
Hatte ich schon versucht, da ist wohl ein Syntaxfehler in meiner
>
> Standardmässig in dem Format, welches du bei der Erstellung der
> Datenbank in der lc_time locale festgelegt hast.
>
> Den aktuellen Stand kannst du mit 'show datestyle;" abfragen und mit
> 'set datestyle <style>;' nach Belieben ändern.
>
> Willst du ein deutsches Datum einfügen, pack vor den Insert ein 'set
> datestyle german;'.
Konfiguration.
> Der Abschnitt 8.5 und der gesamte Anhang B des Manuals beschäftigt sich
> mit diesem Gebiet.
Was ich noch gern wüßte:
Wie machen das andere Datenbanken?
MySQL ist da sehr tolerant und schluckt fast alles als Datum, scheinbar
ist das bei anderen DBen auch so?
Ich habe es hier mit einem Generator zu tun, der nur alle Identifier
quoten kann oder nicht, mehr Auswahl scheint es nicht zu geben. Und die
Datumswerte werden offenbar durch einen Parser geschickt, der alles
andere verwirft:
postgres[5971]: [5-1] ERROR: column "Belegdatum" is of type date but expression is of type character varying at character 23
postgres[5971]: [5-2] HINT: You will need to rewrite or cast the expression.
postgres[5971]: [5-3] STATEMENT: INSERT INTO
postgres[5971]: [5-4] "Journal"("Belegdatum","Buchungsdatum","Belegnummernkreis","Belegnummer","Buchungstext","Buchungsbetrag","Sollkonto","Habenkont o","Steuerschlüssel","Kostenstelle_1","Kostenstelle_2","Währung")
VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12)
Ich hatte schon versucht, die Datumswerte z.B. als <'01.02.03'> oder auch
<date('01.2.03')> reinzureichen, ohne die spitzen Klammern, aber das wird
alles abgetrennt.
Scheinbar kommen andere DBen aber damit zurecht, Fehlermeldungen über dieses
Verhalten finde ich jedenfalls in den Mailinglisten der Software keine.
Dankeschön,
Marc
Marc Santhoff
Jun 23, 2012, 3:23:56 PM6/23/12
to
Ich vergaß:
Alles über JDBC, vielleicht ist da auch der Hund begraben ...
Marc
Alles über JDBC, vielleicht ist da auch der Hund begraben ...
Marc
Marc Santhoff
Jun 23, 2012, 3:47:13 PM6/23/12
to
Noch ein paar Ergänzungen, ich bin wohl schon etwas geschlaucht ...
INSERT INTO "Journal"("Belegdatum","Buchungsdatum","Belegnummernkreis",
"Belegnummer","Buchungstext","Buchungsbetrag","Sollkonto","Habenkonto",
"Steuerschlüssel","Kostenstelle_1","Kostenstelle_2","Währung")
VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12)
Die Daten sehen kurz vor dem Einstöpseln ins Statement so aus:
VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12)
DEBUG [FileReader] JdbcWriter processed 1 input(s) = [1 Output(s)]
DEBUG [FileReader] Executing statement for single record
DEBUG [FileReader] PreparedStatement arg [1] 01.01.2000
DEBUG [FileReader] PreparedStatement arg [2] 12.09.2001
...
DEBUG [FileReader] Exception in writeBatch(): ERROR: column "Belegdatum" is of type date but expression is of type character varying
Hinweis: You will need to rewrite or cast the expression.
Position: 23
...
Also nicht übrig von <date('01.01.2000')> bzw <'01.01.2000'>.
Jedenfalls - und das ist der springende Punkt - kommen wohl
andere DBen damit zurecht?
Ich finde nichts explizites, aber Oracle, SQL Server, HSQL
und noch mehr werden hin und wieder genannt. Eigentlich
aber alles, was via JDBC erreichbar ist.
Marc
Siegfried Schmidt
Jun 23, 2012, 3:47:25 PM6/23/12
to
Marc Santhoff schrieb:
> Wie machen das andere Datenbanken?
> MySQL ist da sehr tolerant und schluckt fast alles als Datum,
> scheinbar ist das bei anderen DBen auch so?
Bei DateTime macht jeder was anderes.
> postgres[5971]: [5-1] ERROR: column "Belegdatum" is of type date but
> expression is of type character varying at character 23
Steht doch da, dass es kein Formatproblem, sondern eine Typverletzung
ist.
Postgres ist relativ typstreng, ein String wird erst zu einem Datum wenn
du ihn explizit als Datum castest.
> o","Steuerschlà Œssel","Kostenstelle_1","Kostenstelle_2","Wà €hrung")
Feldnamen mit Umlauten sind generell eine schlechte Idee.
> Ich hatte schon versucht, die Datumswerte z.B. als <'01.02.03'> oder
> auch <date('01.2.03')> reinzureichen, ohne die spitzen Klammern, aber
> das wird alles abgetrennt.
set datestyle to german;
select '01.2.03'::date;
> Scheinbar kommen andere DBen aber damit zurecht, Fehlermeldungen ÃŒber
Postgres ist bei Datentypen pingeliger, bei Formaten aber genauso
flexibel wie andere.
Siegfried
> Wie machen das andere Datenbanken?
> MySQL ist da sehr tolerant und schluckt fast alles als Datum,
> scheinbar ist das bei anderen DBen auch so?
> postgres[5971]: [5-1] ERROR: column "Belegdatum" is of type date but
> expression is of type character varying at character 23
ist.
Postgres ist relativ typstreng, ein String wird erst zu einem Datum wenn
du ihn explizit als Datum castest.
> o","Steuerschlà Œssel","Kostenstelle_1","Kostenstelle_2","Wà €hrung")
Feldnamen mit Umlauten sind generell eine schlechte Idee.
> Ich hatte schon versucht, die Datumswerte z.B. als <'01.02.03'> oder
> auch <date('01.2.03')> reinzureichen, ohne die spitzen Klammern, aber
> das wird alles abgetrennt.
select '01.2.03'::date;
> Scheinbar kommen andere DBen aber damit zurecht, Fehlermeldungen ÃŒber
> dieses Verhalten finde ich jedenfalls in den Mailinglisten der
> Software keine.
Unterscheide genau zwischen Format- und Typverletzungen.
> Software keine.
Postgres ist bei Datentypen pingeliger, bei Formaten aber genauso
flexibel wie andere.
Siegfried
Siegfried Schmidt
Jun 23, 2012, 3:49:25 PM6/23/12
to
Marc Santhoff schrieb:
> Alles ÃŒber JDBC, vielleicht ist da auch der Hund begraben ...
Es kann sein dass der Treiber beim Start der Verbindung das Datumformat
gem. seiner eigenen Konfig festlegt. Das ist aber einfach überschreibbar.
Siegfried
> Alles ÃŒber JDBC, vielleicht ist da auch der Hund begraben ...
Es kann sein dass der Treiber beim Start der Verbindung das Datumformat
gem. seiner eigenen Konfig festlegt. Das ist aber einfach überschreibbar.
Siegfried
Marc Santhoff
Jun 23, 2012, 4:31:45 PM6/23/12
to
Am Sat, 23 Jun 2012 19:47:25 +0000 schrieb Siegfried Schmidt:
>> Scheinbar kommen andere DBen aber damit zurecht, Fehlermeldungen ÃŒber
>> dieses Verhalten finde ich jedenfalls in den Mailinglisten der Software
>> keine.
>
> Unterscheide genau zwischen Format- und Typverletzungen. Postgres ist
> bei Datentypen pingeliger, bei Formaten aber genauso flexibel wie
> andere.
Jetzt wird's langsaam klarer. Ich hatte angenommen die Typverletzung wäre
>> Scheinbar kommen andere DBen aber damit zurecht, Fehlermeldungen ÃŒber
>> dieses Verhalten finde ich jedenfalls in den Mailinglisten der Software
>> keine.
>
> Unterscheide genau zwischen Format- und Typverletzungen. Postgres ist
> bei Datentypen pingeliger, bei Formaten aber genauso flexibel wie
> andere.
eine Folge des falschen Formate, also daß die Werte als Strings an den DB-
Serverprozeß übergeben und von Postgresql zu lesen versucht werden. Und
genau das scheint falsch zu sein.
Langsam wird es unumgänglich mal die Quelltexte dieses Generators zu
beleuchten ...
Vielen Dank!
Marc
Peter Schneider
Jun 23, 2012, 6:24:17 PM6/23/12
to
Am 23.06.2012 21:21, schrieb Marc Santhoff:
> Am Sat, 23 Jun 2012 19:10:10 +0000 schrieb Siegfried Schmidt:
>
>> Marc Santhoff schrieb:
>>
>>> In welchem Format gebe ich denn mittels psql Datumswerte ein, so daß
>>> ein INSERT auch funktioniert?
[...]
> Am Sat, 23 Jun 2012 19:10:10 +0000 schrieb Siegfried Schmidt:
>
>> Marc Santhoff schrieb:
>>
>>> In welchem Format gebe ich denn mittels psql Datumswerte ein, so daß
>>> ein INSERT auch funktioniert?
> Was ich noch gern wüßte:
>
> Wie machen das andere Datenbanken?
bekommt: der erste ist das Datumsliteral, der zweite ist der Formatstring.
Ergebnistyp ist DATE (welches unter Oracle immer auch einen Zeitanteil mit
Granularität 1sec hat).
Z.B.
INSERT INTO blahblubb
(id, event_date)
VALUES
(1, to_date('24.06.2012', 'DD.MM.YYYY'));
Ohne Formatstring zieht der Default von NLS_DATE_FORMAT (der, wenn nicht
explizit gesetzt, von NLS_TERRITORY abgeleitet ist).
Sobald Namen von Monaten oder Wochentagen ins Spiel kommen ist die
Sessioneinstellung von NLS_LANG relevant.
Für Oracle-Neulinge ist das ganze ein bißchen ein Minenfeld, da es auch eine
implizite Typkonvertierung gibt. Besonders beliebt ist in Oracle Forms die
doppelte implizite (und natürlich falsche;-) Konvertierung wenn Forms Items
oder Forms Globals ins Spiel kommen. Da hab ich schon Pferde ko**en sehen ;-)
Hilft dir wahrscheinlich alles nicht, aber du hattest ja danach gefragt...
Viele Erfolg
Peter
--
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you. -- David McCullough Jr.
0 new messages