Typensicherheit in Postgres 8.3

Hallo,
gestern habe ich einen Postgres Server von 7.2 auf 8.3 upgedated. Nun gibt es in unserem Code einige unschöne Queries, wie folgendes:

SELECT * FROM a WHERE datum LIKE '1970%';

Das schlägt nun fehl, weil datum vom Typ “timestamp with time zone” und der Vergleichswert vom Typ “string” ist.

Da solche Queries tausendfach im alten Code vorkommen, habe ich explizit einen Cast erstellt:

CREATE CAST (timestamp with time zone AS text) WITH FUNCTION pool.text(timestamp with time zone) AS IMPLICIT;

Das funktioniert zwar, aber schöner fände ich, die Typsicherheit komplett abstellen zu können, so dass typecasts wieder implizit stattfinden. Ist das in Version 8.3 möglich?

Vielen Dank für eure Antworten,
viele Grüße
BiBe

hihi …

die postgres-evangelisten werden dir gleich berichten wie toll das ist :slight_smile:

  • soll heissen - das ist so seit 8.3 - in 8.2 wars noch vernuenftig - es wurde verschlimmbessert - musst mit leben

es ist halt das fortschrittlichste DBMS der Welt

Peter Eisentraut hat imho die in 8.3 entfernten Casts irgendwo auf PlanetPostgreSQL abgelegt. Such mal dort in seinem Blog.

Entgegen der lustigen Meinung von symbiont: ein Timestamp ist ein Timestamp und sollte erst mal nicht automatisch als Text behandelt werden. Eine Anwendung, die das voraussetzt, ist falsch programmiert.
Grund: es gibt Funktionen, um genau das richtig zu lösen:

SELECT EXTRACT('year' FROM NOW());

für die welt, dass jeder bestimmen kann was “richtig” und “falsch” ist …

mit deiner aussage stempelst du so ziemlich jede bemuehung - in modernen programmiersprachen - eleganten code zu erzeugen als unsinn ab …

dazu sei gezählt autoboxing - ducktyping - überladen operatoren

vielleicht faellt dir irgendwann mal auf, dass der kleinste gemeinsame nenner aller typen eine darstellung als text/string ist …

man hat es bei der entwicklung von PG einfach versaeumt den string - funktionen bzw. operatoren ein bisschen klugheit beizubringen - oder war zu faul, nach A (wir haben da was konzeptionell tolles) auch B zu sagen (wir machen es transparent)

nun denn … dein “richtig & falsch” in allen ehren - viel spass damit

Es gibt Programmiersprachen und es gibt Programmiersprachen.
Manche haben eine Typisierung, manche nicht.

Die, die keine haben, sind vielleicht einfacher zu erlernen - aber bereiten anderweitig Probleme. Typisierte Sprachen bieten an vielen Stellen Vorteile weil ich mich halt darauf verlassen kann, dort keine anderen Inhalte vorzufinden. Bei einem Integer kann ich mir das Prüfen auf einen String ersparen - und handle mir so keine Sicherheitslücken ein. In einer nicht typisierten Sprache prüft der Programmierer das vielleicht auch nicht - aber dort ist es seine Schuld.

PostgreSQL ist typisiert, also sollte die Bearbeitung auch darauf eingehen. Das ist nur logisch. Was du machst, ist Äpfel mit Pflaumen zu vergleichen. Das eine ist fest, das andere matschig. Soviel zu falsch und richtig …

was fuer ein herrliches Thema :slight_smile:

es gibt “typisierung” und “typisierung” … java z.B. ist auch “typisiert” - war einst sogar strenger als heute - thema autoboxing … ob es leicht zu erlernen ist weiss ich nicht … man kriegt es halt irgendwann mit

damrum geht es aber auch garnich - sondern vielmehr um wartbarkeit - man moechte ja den code nicht nur schreiben, sondern auch in 2 jahren noch verstehen koennen … oder zukunftssicherheit … wäre doch schoen wenn mein code auch spaeter noch funktioniert … das sich zumindest die aenderungen in grenzen halten

während vielerorts begriffen wurde, dass die ganze casterei das leben nicht einfacher macht, fängt man beim “fortschrittlichsten DBMS” an den leuten knueppel zwischen die beine zu werfen …

siehst ja was bei rauskommt … plötzlich funktioniert die anwendung nicht mehr - wegen sowas banalem wie dieser WHERE Klausel …

ich meine ich hatte damit weniger probleme weil meine anwendungen sowieso sql-code erzuegen - da gibts nicht eine statische query … das macht halt der generator … da sind aber noch eine ganze reihe anderer themen wo’s auch hakt - z.B. indexe die ploetzlich nimmer funktionieren usw.

Mach dich mal ruhig weiter unglaubwürdig.

Bevor ich eine Datenbank aktualisiere - speziell über 5 Major Versionen hinweg - prüfe ich vorher, ob das ganze funktioniert. Hinterher schreie ich nicht herum und du wirfst dich auch noch mit aller Macht in die gleiche Bresche.

So, genug der Diskussion. Ich habe die Gründe des PG-Teams vorgestellt, du hast andere Ansichten - schön für dich.

[edit]
major-version von 7.x nach 8.x ist nur eine … du sprichst von MINOR release …

soviel zu “unglaubwuerdig” …

dennoch gebe ich dir recht, dass man da mal gucken kann, was sich so getan hat

ABER die aenderung wurde von 8.2 nach 8.3 vorgenommen - dort hat die einfach nix zu suchen

und dazu ist das problem quasi so banal … dass man durchaus von einer verschlimmbesserung sprechen darf :slight_smile:

Du möchtest Dich mit dem Versionschema von PG beschäftigen. Oder gleich ein anderes System benutzen.

Andreas

@1 was kann ich dafuer wenn PG-entwicker nichtmal in der lage sind jahrhunderte alte konventionen zur vergabe von versionsnummern einzuhalten?

@2 kann ich mir leider nicht (immer) aussuchen …

Die Diskussion um “vor dem Punkt ist Major” ist so alt wie die Versionierung von Programmen selbst. Manche halten sich streng an “Major-Minor-Micro”, für manche ist der Schritt von 8.2 auf 8.3 einfach ein Major Release.

Letztendlich - und das ist der springende Punkt - bestimmt der Entwickler selbst, was ein Major Release ist. Wie er seine Versionsnummern führt, bleibt völlig ihm überlassen. PostgreSQL ist halt jetzt noch nicht bei Versionsnummer 15 oder 16 sondern bei 8.3.

Ansonsten könnte man genauso argumentieren, das Apache 2.0 und 2.2 oder Linux Kernel 2.4 und 2.6 sich nicht großartig unterscheiden. Das waren ja deiner Meinung nach keine Major-Releases.