Re: Zeit und Zeitzonen richtig konfigurieren

Johannes Brügmann schrob:

> Eine Frage hätte ich dann aber doch noch:
> Was passiert bei
>
> - PGTZ=CET und '01.01.2006 12:00:00 +01' (Postgres speichert
> '01.01.2006 10:00:00 UTC', oder?)
>
> - PGTZ=CET und '01.04.2006 12:00:00 +01' (Postgres speichert
> '01.04.2006 09:00:00 UTC', oder?)

Nein.

<http://www.postgresql.org/docs/8.0/static/datatype-datetime.html#AEN4516>

--8<---------------cut here---------------start------------->8---
An input value that has an explicit time zone specified is converted
to UTC using the appropriate offset for that time zone. If no time
zone is stated in the input string, then it is assumed to be in the
time zone indicated by the system's timezone parameter, and is
converted to UTC using the offset for the `timezone' zone.
--8<---------------cut here---------------end--------------->8---

> Eigentlich wäre eine solche Ergänzung mit einem oder mehreren guten
> Beispielen in der Dokumentation eine feine Sache (pro bono, contra
> malum ;-).

Hmm, auch zum ursprünglichen Problem - Zeitzone als Ort vs. Offset -
findet sich ein Hinweis im Handbuch:

<http://www.postgresql.org/docs/8.0/static/datetime-keywords.html#DATETIME-TIMEZONE-SET-TABLE>

--8<---------------cut here---------------start------------->8---
Note that these names are conceptually as well as practically
different from the names shown in Table B-4: most of these names imply
a local daylight-savings time rule, whereas the former names each
represent just a fixed offset from UTC.
--8<---------------cut here---------------end--------------->8---

Aber ich muß zugeben, daß letzteres im Anhang etwas versteckt ist.

>> Auf der Platte liegt nur UTC, ein Update einer timestamptz-Spalte
>> macht also nur Sinn, wenn man PostgreSQL einmal über die verwendete
>> Zeitzone getäuscht hat, und UTC deswegen nicht UTC ist.
>
> Ich habe PostgreSQL seit Beginn der Sommerzeit über die wahre Zeit
> getäuscht. Einen ersten UPDATE-Versuch wies PostgreSQL aber zurück mit
> der Begründung, dass Fremdschlüssel kollidieren würden. Ich denke, das
> liegt wohl an der falschen Reihenfolge. Führt PostgreSQL eigentlich
> eine UPDATE-Anfrage auf mehreren Tupeln parallel aus?

Offensichtlich nicht :-/. Man scheint die Reihenfolge des UPDATEs aber
mit CLUSTER hinbiegen zu können. Aber irnkwie sieht mir das mehr nach
einem ekligen Hack als nach einem Feature aus...

--8<---------------cut here---------------start------------->8---
scratch=# UPDATE bar set a = a + 1 ;
ERROR: duplicate key violates unique constraint "bar_pkey"
scratch=# create index temp_idx on bar((-a));
CREATE INDEX
scratch=# cluster temp_idx on bar;
CLUSTER
scratch=# UPDATE bar set a = a + 1 ;
UPDATE 3
scratch=#
--8<---------------cut here---------------end--------------->8---

...damit wäre dann die Kollison ausgeschlossen, aber ich fürchte,
damit das Update klappt, müssen die Fremdschlüssel entweder ON UPDATE
CASCADE sein, oder man muss sie temporär abschalten (ALTER TABLE
... DISABLE TRIGGER ALL sollte das leisten).

Auf jeden Fall beim Experimentieren das ROLLBACK griffbereit halten
:-).

Gruß + viel Erfolg beim Update
Andreas