PostgreSQL: Nachkommastellen bei NUMERIC
Frank Seitz
ich habe eine Kolumne mit NUMERIC(16,8) vereinbart, also mit
8 signifikanten Nachkommastellen. Nun stelle ich fest,
dass PostgreSQL diese 8 Stellen grundsätzlich liefert, egal wie
viele Nachkommastellen die Zahl tatsächlich hat.
Also statt 7.41 wird 7.41000000 geliefert.
Kann man das Auffüllen mit Nullen irgendwie abstellen?
Grüße
Frank Seitz
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Siegfried Schmidt
> dass PostgreSQL diese 8 Stellen grundsätzlich liefert, egal wie
> viele Nachkommastellen die Zahl tatsächlich hat.
> Also statt 7.41 wird 7.41000000 geliefert.
Wenn du 8 Stellen festlegst, hat 7.41 die Genauigkeit von 8
Nachkommastellen wie jeder andere Wert auch.
> Kann man das Auffüllen mit Nullen irgendwie abstellen?
Nicht mit dem Numeric-Typ.
Du kannst aber zur Anzeige den Wert in einen Text umwandeln und die
nachlaufenden Nullen trimmen:
select trim(trailing '0' from wert::text);
Siegfried
--
http://www.schmidt.ath.cx
Tim Landscheidt
> [...]
>> Kann man das Auffüllen mit Nullen irgendwie abstellen?
> Nicht mit dem Numeric-Typ.
> Du kannst aber zur Anzeige den Wert in einen Text umwandeln und die
> nachlaufenden Nullen trimmen:
> select trim(trailing '0' from wert::text);
... was dann aber bei ganzzahligen Werten zu "1." führt,
ebenso wie bei "TO_CHAR(wert, 'FM999.999')".
Tim
Siegfried Schmidt
> ... was dann aber bei ganzzahligen Werten zu "1." führt,
> ebenso wie bei "TO_CHAR(wert, 'FM999.999')".
Ein bischen Schwund ist immer. Aber es gibt ja auch noch regexp_replace(),
für den richtigen Ausdruck fehlt mir jetzt grad die Zeit, das kann jemand
anders sicher noch nachliefern.
Siegfried
--
http://www.schmidt.ath.cx
Andreas Kretschmer
... was man wiederum mit anderen Stringfunktionen schön machen kann.
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Bernd Nawothnig
> ich habe eine Kolumne mit NUMERIC(16,8) vereinbart, also mit 8
> signifikanten Nachkommastellen. Nun stelle ich fest, dass PostgreSQL
> diese 8 Stellen grundsätzlich liefert, egal wie viele
> Nachkommastellen die Zahl tatsächlich hat. Also statt 7.41 wird
> 7.41000000 geliefert. Kann man das Auffüllen mit Nullen irgendwie
> abstellen?
Sowas gehört in die Anwendung bzw. Ausgabe und ist nicht dem Datentyp
an sich anzukreiden:
sed 's/0*$//;s/\.$//'
oder so ...
Bernd
--
No time toulouse
Frank Seitz
>> dass PostgreSQL diese 8 Stellen grundsätzlich liefert, egal wie
>> viele Nachkommastellen die Zahl tatsächlich hat.
>> Also statt 7.41 wird 7.41000000 geliefert.
>
> Wenn du 8 Stellen festlegst, hat 7.41 die Genauigkeit von 8
> Nachkommastellen wie jeder andere Wert auch.
Was willst du damit sagen? Dass die Nullen am Ende in irgendeiner
Weise notwendig sind?
>> Kann man das Auffüllen mit Nullen irgendwie abstellen?
>
> Nicht mit dem Numeric-Typ.
Ich wechsle auch gerne auf einen anderen Typ, wenn dieser den
Effekt nicht hat.
> Du kannst aber zur Anzeige den Wert in einen Text umwandeln und die
> nachlaufenden Nullen trimmen:
>
> select trim(trailing '0' from wert::text);
Eine Spezialbehandlung möchte ich vermeiden, da es nicht um ein Query
und eine Kolumne geht, sondern um recht viele Queries und Kolumnen.
Frank Seitz
> On 2009-04-16, Frank Seitz wrote:
>>
>> ich habe eine Kolumne mit NUMERIC(16,8) vereinbart, also mit 8
>> signifikanten Nachkommastellen. Nun stelle ich fest, dass PostgreSQL
>> diese 8 Stellen grundsätzlich liefert, egal wie viele
>> Nachkommastellen die Zahl tatsächlich hat. Also statt 7.41 wird
>> 7.41000000 geliefert. Kann man das Auffüllen mit Nullen irgendwie
>> abstellen?
>
> Sowas gehört in die Anwendung bzw. Ausgabe und ist nicht dem Datentyp
> an sich anzukreiden:
Das sehe ich anders. Oracle z.B. lässt die informationslosen
Nullen weg.
> sed 's/0*$//;s/\.$//'
>
> oder so ...
Ist klar, dass sich das mit einem Regex wegbügeln lässt,
möchte das nur nicht überall machen müssen. Ich portiere eine
Anwendung, die das bislang nicht brauchte.
Lutz Donnerhacke
>> select trim(trailing '0' from wert::text);
>
> Eine Spezialbehandlung möchte ich vermeiden, da es nicht um ein Query
> und eine Kolumne geht, sondern um recht viele Queries und Kolumnen.
Schieb's in einen View.
Stefan Moeding
Frank Seitz writes:
> Ist klar, dass sich das mit einem Regex wegbügeln lässt,
> möchte das nur nicht überall machen müssen. Ich portiere eine
> Anwendung, die das bislang nicht brauchte.
Hast du mal nur NUMERIC probiert?
sm@dev=> create table t (a numeric, b numeric(16,8));
CREATE TABLE
sm@dev=> insert into t values (1,1);
INSERT 0 1
sm@dev=> insert into t values (1.0,1.0);
INSERT 0 1
sm@dev=> insert into t values (1.01,1.01);
INSERT 0 1
sm@dev=> select * from t;
a | b
------+------------
1 | 1.00000000
1.0 | 1.00000000
1.01 | 1.01000000
(3 rows)
Du bekommst dann aber andere Effekte, die du vielleicht nicht möchtest.
Das Einfügen einer sehr großen Zahl geht in NUMERIC ohne Probleme,
während das bei NUMERIC(16,8) einen Fehler gibt, denn man eventuell
abfangen möchte. Und mehr als 8 Nachkommastellen gehen da auch rein.
--
Stefan
Harald Wenninger
> Bernd Nawothnig wrote:
>> On 2009-04-16, Frank Seitz wrote:
>>> ich habe eine Kolumne mit NUMERIC(16,8) vereinbart, also mit 8
>>> signifikanten Nachkommastellen. Nun stelle ich fest, dass PostgreSQL
>>> diese 8 Stellen grundsätzlich liefert, egal wie viele
>>> Nachkommastellen die Zahl tatsächlich hat. Also statt 7.41 wird
>>> 7.41000000 geliefert. Kann man das Auffüllen mit Nullen irgendwie
>>> abstellen?
>> Sowas gehört in die Anwendung bzw. Ausgabe und ist nicht dem Datentyp
>> an sich anzukreiden:
> Das sehe ich anders. Oracle z.B. lässt die informationslosen
> Nullen weg.
Die Nullen sind nicht informationslos. Du hast doch selbst acht Stellen
Genauigkeit verlangt.
Abgesehen davon könntest du den Typ für die Ausgabe auf einen floating
point Datentyp casten, dann fallen die Nullen weg.
Gruß,
Harald
Frank Seitz
> Frank Seitz writes:
>>
>> Ist klar, dass sich das mit einem Regex wegbügeln lässt,
>> möchte das nur nicht überall machen müssen. Ich portiere eine
>> Anwendung, die das bislang nicht brauchte.
>
> Hast du mal nur NUMERIC probiert?
>
> sm@dev=> create table t (a numeric, b numeric(16,8));
> CREATE TABLE
> sm@dev=> insert into t values (1,1);
> INSERT 0 1
> sm@dev=> insert into t values (1.0,1.0);
> INSERT 0 1
> sm@dev=> insert into t values (1.01,1.01);
> INSERT 0 1
> sm@dev=> select * from t;
> a | b
> ------+------------
> 1 | 1.00000000
> 1.0 | 1.00000000
> 1.01 | 1.01000000
> (3 rows)
Guter Vorschlag! Das funktioniert.
> Du bekommst dann aber andere Effekte, die du vielleicht nicht möchtest.
> Das Einfügen einer sehr großen Zahl geht in NUMERIC ohne Probleme,
> während das bei NUMERIC(16,8) einen Fehler gibt, denn man eventuell
> abfangen möchte. Und mehr als 8 Nachkommastellen gehen da auch rein.
Das ist ein wesentlich geringeres, evtl. gar kein Problem.
Grüße
Frank
Frank Seitz
>>
>> Das sehe ich anders. Oracle z.B. lässt die informationslosen
>> Nullen weg.
>
> Die Nullen sind nicht informationslos.
Meiner Meinung nach sind die angehängten Nullen
semantisch nutzlos. Welche Information tragen sie denn,
deiner Meinung nach?
> Du hast doch selbst acht Stellen Genauigkeit verlangt.
Um genau zu sein: Ich habe 16 Stellen Genauigkeit verlangt,
davon 8 Nachkommastellen.
> Abgesehen davon könntest du den Typ für die Ausgabe auf einen floating
> point Datentyp casten, dann fallen die Nullen weg.
Wie ich schon sagte, will ich keine Einzelfallbehandlung.
Aber mit NUMERIC ohne Precision/Scale ist das Verhalten so
wie ich es mir wünsche. Problem also gelöst.
Harald Wenninger
>>> Das sehe ich anders. Oracle z.B. lässt die informationslosen
>>> Nullen weg.
>> Die Nullen sind nicht informationslos.
> Meiner Meinung nach sind die angehängten Nullen
> semantisch nutzlos. Welche Information tragen sie denn,
> deiner Meinung nach?
Dass die Zahl auf acht Stellen hinter dem Komma genau ist.
Gruß,
Harald
Frank Seitz
> * Frank Seitz tat kund und zu wissen:
>>>> Das sehe ich anders. Oracle z.B. lässt die informationslosen
>>>> Nullen weg.
>>> Die Nullen sind nicht informationslos.
>> Meiner Meinung nach sind die angehängten Nullen
>> semantisch nutzlos. Welche Information tragen sie denn,
>> deiner Meinung nach?
>
> Dass die Zahl auf acht Stellen hinter dem Komma genau ist.
Wenn eine Zahl nur zwei Nachkommastellen hat, ist sie
auch auf acht Stellen genau. Wo eine Rundung einsetzt ersehe
ich am Datentyp, nicht an der Schreibweise der Zahl.
In einigen Anwendungen mag diese Darstellung sinnvoll sein,
speziell in Formularen ist sie Augenfutter.
Siegfried Schmidt
> Was willst du damit sagen? Dass die Nullen am Ende in irgendeiner
> Weise notwendig sind?
Die Nullen sind dann nötig, wenn der Wert eine bestimmte Genauigkeit
repräsentieren soll. 7.41 ist in der Technik etwas anderes als 7.41000.
Das ist im Fall der Datenbank aber anders, sie hat ausser in
Ausnahmefällen nichts mit der externen Darstellung zu tun. Sie hat also
auch keinen Anlass, Werte irgendwie anders als nach der Typeinstellung zu
liefern.
Im übrigen sind die Nullen ja nur ein Aspekt - das Dezimaltrennzeichen
und die fehlenden Tausenderpunkte sind hierzulande doch mindestens
genauso falsch oder störend.
> Eine Spezialbehandlung möchte ich vermeiden, da es nicht um ein Query
> und eine Kolumne geht, sondern um recht viele Queries und Kolumnen.
Die Konvertierung von Werten von internen nach externer Darstellung ist
keine Spezialbehandlung, sondern extra so vorgesehen und die
Daseinsberechtigung der diversen Formatierungmöglichkeiten der to_char-
Familie - wenn das Frontend diese Aufgabe nicht übernimmt.
Siegfried
--
http://www.schmidt.ath.cx
Frank Seitz
>>
>> Was willst du damit sagen? Dass die Nullen am Ende in irgendeiner
>> Weise notwendig sind?
>
> Die Nullen sind dann nötig, wenn der Wert eine bestimmte Genauigkeit
> repräsentieren soll. 7.41 ist in der Technik etwas anderes als 7.41000.
Na schön, nehme ich das als Standpunkt mal hin. Für mich
(als Informatiker) macht es sematisch keinen Unterschied.
> Das ist im Fall der Datenbank aber anders, sie hat ausser in
> Ausnahmefällen nichts mit der externen Darstellung zu tun. Sie hat also
> auch keinen Anlass, Werte irgendwie anders als nach der Typeinstellung zu
> liefern.
Jein. Mindestens im Bereich der Datumsdarstellung gibt es
solche Einstellmöglichkeiten.
> Im übrigen sind die Nullen ja nur ein Aspekt - das Dezimaltrennzeichen
> und die fehlenden Tausenderpunkte sind hierzulande doch mindestens
> genauso falsch oder störend.
Das ist u.U. auch eine Einstellungssache (I18N-Optionen).
>> Eine Spezialbehandlung möchte ich vermeiden, da es nicht um ein Query
>> und eine Kolumne geht, sondern um recht viele Queries und Kolumnen.
>
> Die Konvertierung von Werten von internen nach externer Darstellung ist
> keine Spezialbehandlung, sondern extra so vorgesehen und die
> Daseinsberechtigung der diversen Formatierungmöglichkeiten der to_char-
> Familie - wenn das Frontend diese Aufgabe nicht übernimmt.
Grundsätzlich ist das richtig. Dennoch wird man nach Alternativen
fragen dürfen. Es hat sich auf dem Weg ja auch eine Lösung gefunden.
Kay Kanekowski
> Die Nullen sind dann nötig, wenn der Wert eine bestimmte Genauigkeit
> repräsentieren soll. 7.41 ist in der Technik etwas anderes als 7.41000.
>
wo ist denn da der Unterschied ?
Bin auch nur Informatiker, habe aber auch vor 30 Jahren 'ne Lehre als
Feinmechaniker abgeschlossen. D.h. im Mikrometerbereich war ich durchaus
mal zu hause. Und ich würde mal sagen, 1 mm ist 1 mm. Ob ich ihn jetzt
mit dem Zollstock oder mit der Mikrometerschraube messe. Nur ich weiß in
dem Moment um die unterschiedliche Genauigkeit der Messung.
Aber ob jetzt der Wert 7,41 oder der Wert 7,41000 mit einem genaueren
Werkzeug/Messverfahren ermittelt wurde, sieht man ihm so nicht. Also
sind die Werte für mich erstmal gleich.
Andersrum sieht doch der Wert 53,846... Prozent höllisch genau ermittelt
aus, oder ? Na, ja, es ist aber auch nur ne Aussage, die 7 von 13
Befragten bejahen.
scnr
Kay
Siegfried Schmidt
> Na schön, nehme ich das als Standpunkt mal hin. Für mich
> (als Informatiker) macht es sematisch keinen Unterschied.
Hmm, ich hätte jetzt fast gewettet, dass auch in diversen Computersprachen
mit 1 und 1.0 nicht das gleiche gemeint ist.
Siegfried
--
http://www.schmidt.ath.cx
Lutz Donnerhacke
> Hallo Siegfried,
>> Die Nullen sind dann nötig, wenn der Wert eine bestimmte Genauigkeit
>> repräsentieren soll. 7.41 ist in der Technik etwas anderes als 7.41000.
>
> wo ist denn da der Unterschied ?
Das Stichwort, das Du suchst, heißt "signifikante Stellen".
Siegfried Schmidt
> Andersrum sieht doch der Wert 53,846... Prozent höllisch genau ermittelt
> aus, oder ? Na, ja, es ist aber auch nur ne Aussage, die 7 von 13
> Befragten bejahen.
Obwohl du keinen Unterschied zu sehen glaubst, ist dir doch zur falschen
Anwendung gültiger Ziffern gleich ein gutes Beispiel eingefallen. ;-)
Ansonsten siehe z.B.
<http://leifi.physik.uni-muenchen.de/web_ph08/grundwissen/05
_genauigkeit/gruwi_genauigkeit.htm>
Siegfried
--
http://www.schmidt.ath.cx
Frank Seitz
>>
>> Na schön, nehme ich das als Standpunkt mal hin. Für mich
>
> Hmm, ich hätte jetzt fast gewettet, dass auch in diversen Computersprachen
> mit 1 und 1.0 nicht das gleiche gemeint ist.
Das können u.U. Literale unterschiedlicher Datentypen
sein (Integer, Float), was aber ein ganz anderes Thema ist.
Kay Kanekowski
in dem Fall, wo sich alle an eine wie auch immer geartete Konvention
halten, unterscheiden sich die Werte in der Genauigkeit der Messung.
Der Wert an sich ist aber trotzdem derselbe.
Ich hatte mal bei der Marine ein Seezielschießen dokumentieren müssen.
Unter anderem wird der Abstand zum Ziel eingetragen. Den konnte man am
Radar auf Zehntel Seemeilen ablesen, na ja so ungefähr jedenfalls.
Eingetragen werden musste aber der Abstand in Metern.
So eine Seemeile hat 1852 m. Also übern Daumen: Seemeilen mal 2 und dann
minus 10 Prozent. Und dann hinten noch auf 100 m runden. Und so sahen
dann meine Zahlen und die der anderen WOs auch aus.
Nur einer, der hatte einen Taschenrechner und machte davon regen Gebrauch...
Der hatte dann Meter genaue Abstände eingetragen...
Das Ende vom Lied war ein fürchterlicher Krach vom Ari-Meister...
Zuviel (scheinbare) Genauigkeit hilft also auch nicht immer.
Kay
Kristian Köhntopp
<usen...@schmidt.ath.cx> said:
> Hallo Frank,
>
>> Na schön, nehme ich das als Standpunkt mal hin. Für mich
>> (als Informatiker) macht es sematisch keinen Unterschied.
>
> Hmm, ich hätte jetzt fast gewettet, dass auch in diversen Computersprachen
> mit 1 und 1.0 nicht das gleiche gemeint ist.
Schon, aber wenn Du zurück gehst, wirst Du sehen, daß es um 1. (Eins
Punkt) und 1.0 (Eins Punkt Null) ging.
Kris
Siegfried Schmidt
> Das können u.U. Literale unterschiedlicher Datentypen
> sein (Integer, Float), was aber ein ganz anderes Thema ist.
Fragtest du nicht, ob "die Nullen am Ende in irgendeiner
Weise notwendig sind"?
Siegfried
--
http://www.schmidt.ath.cx
Frank Seitz
>>
>> Das können u.U. Literale unterschiedlicher Datentypen
>> sein (Integer, Float), was aber ein ganz anderes Thema ist.
>
> Fragtest du nicht, ob "die Nullen am Ende in irgendeiner
> Weise notwendig sind"?
Kristian Köhntopp hat es schon gesagt: In dem Fall
geht es nicht um die Nullen, sondern das Dezimaltrennzeichen.
1.0 statt 1 wäre ok für mich, aber nicht 1.00000000.
Frank Seitz
Solchen Schwachsinn kann man wahrscheinlich nur beim Militär erleben :)