Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #569120 > unrolled thread

Postgressql

Back to article view | Back to ger.ct

Contents

  Postgressql Goetz Schultz <news.expire1225@goetz.co.uk> - 2022-10-02 19:23 +0100
    Re: Postgressql Michael Bode <m.g.bode@web.de> - 2022-10-02 20:43 +0200
      Re: Postgressql Goetz Schultz <news.expire1225@goetz.co.uk> - 2022-10-02 19:46 +0100
        Re: Postgressql Michael Bode <m.g.bode@web.de> - 2022-10-02 20:52 +0200
          Re: Postgressql Goetz Schultz <news.expire1225@goetz.co.uk> - 2022-10-02 19:59 +0100
            Re: Postgressql Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-10-03 08:01 +0000
          Re: Postgressql Goetz Schultz <news.expire1225@goetz.co.uk> - 2022-10-03 10:30 +0100
    Re: Postgressql Goetz Schultz <news.expire1225@goetz.co.uk> - 2022-10-02 19:44 +0100
      Re: Postgressql Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-10-03 08:06 +0000
        Re: Postgressql Michael Bode <m.g.bode@web.de> - 2022-10-03 10:15 +0200
          Re: Postgressql Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-10-03 09:57 +0000
          Re: Postgressql Michael Bode <m.g.bode@web.de> - 2022-10-03 12:12 +0200

#569120 — Postgressql

Hi,

ich stehe vor einem Problem, wo ich nicht weiss ob es nicht geht und 
deshalb keine Antwort finde oder einfach nur falsch suche:

In einem SELECT-Statement ist eines der Felder ein BigInt. Ich moechte 
von dem BigInt-wert die letzten beiden Ziffern wegfallen lassen (also 
statt 10 nur 8 Ziffern). Geht das mit Bordmitteln (Skripten /nach/ der 
Ausgabe geht, ist aber suboptimal).

Danke im vorraus.

-- 

Cheers,
    G.

Quis custodiet ipsos custodes?
---------------------------->8------------------------------
   /"\
   \ /  ASCII Ribbon Campaign
    X   against HTML e-mail
   / \
---------------------------->8------------------------------

[toc] | [next] | [standalone]

#569124

Goetz Schultz <news.expire1225@goetz.co.uk> writes:

> Hi,
>
> ich stehe vor einem Problem, wo ich nicht weiss ob es nicht geht und
> deshalb keine Antwort finde oder einfach nur falsch suche:
>
> In einem SELECT-Statement ist eines der Felder ein BigInt. Ich moechte
> von dem BigInt-wert die letzten beiden Ziffern wegfallen lassen (also
> statt 10 nur 8 Ziffern). Geht das mit Bordmitteln (Skripten /nach/ der
> Ausgabe geht, ist aber suboptimal).

select column / 100 from table;

Oder verstehe ich das Problem nicht?

-- 
"Die Abwesenheit von Evidenz zur Wirksamkeit ist keine Evidenz 
für die Abwesenheit von Wirksamkeit."
 - Der Grünen-Gesundheitsexperte Janosch Dahmen.

[toc] | [prev] | [next] | [standalone]

#569126

On 02/10/2022 19:43, Michael Bode wrote:
> Goetz Schultz <news.expire1225@goetz.co.uk> writes:
> 
>> Hi,
>>
>> ich stehe vor einem Problem, wo ich nicht weiss ob es nicht geht und
>> deshalb keine Antwort finde oder einfach nur falsch suche:
>>
>> In einem SELECT-Statement ist eines der Felder ein BigInt. Ich moechte
>> von dem BigInt-wert die letzten beiden Ziffern wegfallen lassen (also
>> statt 10 nur 8 Ziffern). Geht das mit Bordmitteln (Skripten /nach/ der
>> Ausgabe geht, ist aber suboptimal).
> 
> select column / 100 from table;
> 
> Oder verstehe ich das Problem nicht?
> 

Das gibt die anstatt 123456789 eben 1234567.89. Verschiebt nur den 
Dezimalpunkt.
Stefan's Antwort geht schon in die richtige Richtung.
-- 

Cheers,
    G.

Quis custodiet ipsos custodes?
---------------------------->8------------------------------
   /"\
   \ /  ASCII Ribbon Campaign
    X   against HTML e-mail
   / \
---------------------------->8------------------------------

[toc] | [prev] | [next] | [standalone]

#569127

Goetz Schultz <news.expire1225@goetz.co.uk> writes:

> On 02/10/2022 19:43, Michael Bode wrote:
>> Goetz Schultz <news.expire1225@goetz.co.uk> writes:
>> 
>>> Hi,
>>>
>>> ich stehe vor einem Problem, wo ich nicht weiss ob es nicht geht und
>>> deshalb keine Antwort finde oder einfach nur falsch suche:
>>>
>>> In einem SELECT-Statement ist eines der Felder ein BigInt. Ich moechte
>>> von dem BigInt-wert die letzten beiden Ziffern wegfallen lassen (also
>>> statt 10 nur 8 Ziffern). Geht das mit Bordmitteln (Skripten /nach/ der
>>> Ausgabe geht, ist aber suboptimal).
>> select column / 100 from table;
>> Oder verstehe ich das Problem nicht?
>> 
>
> Das gibt die anstatt 123456789 eben 1234567.89. Verschiebt nur den
> Dezimalpunkt.
> Stefan's Antwort geht schon in die richtige Richtung.

Dann habe ich hier eine andere PostgreSQL Version.

select 1234567890 / 100;
 ?column? 
----------
 12345678
(1 row)

-- 
"Die Abwesenheit von Evidenz zur Wirksamkeit ist keine Evidenz 
für die Abwesenheit von Wirksamkeit."
 - Der Grünen-Gesundheitsexperte Janosch Dahmen.

[toc] | [prev] | [next] | [standalone]

#569129

On 02/10/2022 19:52, Michael Bode wrote:
> Goetz Schultz <news.expire1225@goetz.co.uk> writes:
> 
>> On 02/10/2022 19:43, Michael Bode wrote:
>>> Goetz Schultz <news.expire1225@goetz.co.uk> writes:
>>>
>>>> Hi,
>>>>
>>>> ich stehe vor einem Problem, wo ich nicht weiss ob es nicht geht und
>>>> deshalb keine Antwort finde oder einfach nur falsch suche:
>>>>
>>>> In einem SELECT-Statement ist eines der Felder ein BigInt. Ich moechte
>>>> von dem BigInt-wert die letzten beiden Ziffern wegfallen lassen (also
>>>> statt 10 nur 8 Ziffern). Geht das mit Bordmitteln (Skripten /nach/ der
>>>> Ausgabe geht, ist aber suboptimal).
>>> select column / 100 from table;
>>> Oder verstehe ich das Problem nicht?
>>>
>>
>> Das gibt die anstatt 123456789 eben 1234567.89. Verschiebt nur den
>> Dezimalpunkt.
>> Stefan's Antwort geht schon in die richtige Richtung.
> 
> Dann habe ich hier eine andere PostgreSQL Version.
> 
> select 1234567890 / 100;
>   ?column?
> ----------
>   12345678
> (1 row)
> 

Ok, zugegeben, war nur vom anschauen - ich habe gerade nicht den Zugang 
zu der DB. Aber das werde ich auch antesten. Danke!
-- 

Cheers,
    G.

Quis custodiet ipsos custodes?
---------------------------->8------------------------------
   /"\
   \ /  ASCII Ribbon Campaign
    X   against HTML e-mail
   / \
---------------------------->8------------------------------

[toc] | [prev] | [next] | [standalone]

#569166

On Sun, 02 Oct 2022 20:59:58 Goetz Schultz wrote:
> On 02/10/2022 19:52, Michael Bode wrote:
>> Goetz Schultz <news.expire1225@goetz.co.uk> writes:
>>>>> In einem SELECT-Statement ist eines der Felder ein BigInt. Ich
>>>>> moechte von dem BigInt-wert die letzten beiden Ziffern
>>>>> wegfallen lassen (also statt 10 nur 8 Ziffern). Geht das mit
>>>>> Bordmitteln (Skripten /nach/ der Ausgabe geht, ist aber
>>>>> suboptimal).

>>>> select column / 100 from table;
>>>> Oder verstehe ich das Problem nicht?

>>> Das gibt die anstatt 123456789 eben 1234567.89. Verschiebt nur
>>> den Dezimalpunkt.
>>> Stefan's Antwort geht schon in die richtige Richtung.

>> Dann habe ich hier eine andere PostgreSQL Version.
>> 
>> select 1234567890 / 100;
>>   ?column?
>> ----------
>>   12345678
>> (1 row)
>> 
 
> Ok, zugegeben, war nur vom anschauen - ich habe gerade nicht den
> Zugang zu der DB. Aber das werde ich auch antesten. Danke!

Wenn beide Argumente Integer sind, ist auch das Ergebnis ein
Integer. Auf der Befehlszeile und mit Zahlen klappt das also
zuverlässig, in allen anderen Fällen bleibt das Restrisiko, sich
beim Typ der Argumente geirrt zu haben:

#v+
> select 12345678.0 / 100.0;
      ?column?
---------------------
 123456.780000000000
(1 row)
#v-

Hast Du Sorge, dass das passieren könnte, kannst Du:

a) Typsicherheit herstellen:

#v+
> select 12345678.0::int / 100.0::int;
 ?column?
----------
   123456
(1 row)
#v-

b) die Nachkommastellen entfernen:

#v+
select floor(12345678.0 / 100.0);
 floor
--------
 123456
(1 row)
#v-

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Reizende Notare nimmt der deutsche Staat: Stefan!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#569176

On 02/10/2022 19:52, Michael Bode wrote:
> Goetz Schultz <news.expire1225@goetz.co.uk> writes:
> 
>> On 02/10/2022 19:43, Michael Bode wrote:
>>> Goetz Schultz <news.expire1225@goetz.co.uk> writes:
>>>
>>>> Hi,
>>>>
>>>> ich stehe vor einem Problem, wo ich nicht weiss ob es nicht geht und
>>>> deshalb keine Antwort finde oder einfach nur falsch suche:
>>>>
>>>> In einem SELECT-Statement ist eines der Felder ein BigInt. Ich moechte
>>>> von dem BigInt-wert die letzten beiden Ziffern wegfallen lassen (also
>>>> statt 10 nur 8 Ziffern). Geht das mit Bordmitteln (Skripten /nach/ der
>>>> Ausgabe geht, ist aber suboptimal).
>>> select column / 100 from table;
>>> Oder verstehe ich das Problem nicht?
>>>
>>
>> Das gibt die anstatt 123456789 eben 1234567.89. Verschiebt nur den
>> Dezimalpunkt.
>> Stefan's Antwort geht schon in die richtige Richtung.
> 
> Dann habe ich hier eine andere PostgreSQL Version.
> 
> select 1234567890 / 100;
>   ?column?
> ----------
>   12345678
> (1 row)
> 

So, getestet - funktioniert. Danke.
-- 

Cheers,
    G.

Quis custodiet ipsos custodes?
---------------------------->8------------------------------
   /"\
   \ /  ASCII Ribbon Campaign
    X   against HTML e-mail
   / \
---------------------------->8------------------------------

[toc] | [prev] | [next] | [standalone]

#569125

On 02/10/2022 19:39, Stefan Ram wrote:
> Goetz Schultz <news.expire1225@goetz.co.uk> writes:
>> In einem SELECT-Statement ist eines der Felder ein BigInt. Ich moechte
>> von dem BigInt-wert die letzten beiden Ziffern wegfallen lassen (also
>> statt 10 nur 8 Ziffern). Geht das mit Bordmitteln (Skripten /nach/ der
>> Ausgabe geht, ist aber suboptimal).
> 
>    Ich habe hier leider nur MySQL 8.0 zur Hand.
>    Damit habe ich jetzt folgendes ausprobiert:
> 
> |
> |mysql> USE D
> |Database changed
> |
> |mysql> CREATE TABLE T( F BIGINT );
> |Query OK, 0 rows affected (0.14 sec)
> |
> |mysql> INSERT INTO T( F )VALUES( 123456789 );
> |Query OK, 1 row affected (0.07 sec)
> |
> |mysql> SELECT LEFT(F,LENGTH(F)-2) FROM T;
> |+---------------------+
> || LEFT(F,LENGTH(F)-2) |
> |+---------------------+
> || 1234567             |
> |+---------------------+
> |1 row in set (0.00 sec)
> |
> 
>    .
> 
> 

Ah, das sieht schon mal gut aus. Sollte auch mit PSQL gehen .....

-- 

Cheers,
    G.

Quis custodiet ipsos custodes?
---------------------------->8------------------------------
   /"\
   \ /  ASCII Ribbon Campaign
    X   against HTML e-mail
   / \
---------------------------->8------------------------------

[toc] | [prev] | [next] | [standalone]

#569167

On Sun, 02 Oct 2022 20:44:41 Goetz Schultz wrote:
> On 02/10/2022 19:39, Stefan Ram wrote:
>> Goetz Schultz <news.expire1225@goetz.co.uk> writes:
>>> In einem SELECT-Statement ist eines der Felder ein BigInt. Ich
>>> moechte von dem BigInt-wert die letzten beiden Ziffern wegfallen
>>> lassen (also statt 10 nur 8 Ziffern). Geht das mit Bordmitteln
>>> (Skripten /nach/ der Ausgabe geht, ist aber suboptimal).

[F == 123456789]
>> |mysql> SELECT LEFT(F,LENGTH(F)-2) FROM T;
>> |+---------------------+
>> || LEFT(F,LENGTH(F)-2) |
>> |+---------------------+
>> || 1234567             |
>> |+---------------------+
>> |1 row in set (0.00 sec)

> Ah, das sieht schon mal gut aus. Sollte auch mit PSQL gehen .....

Das ist *so* grausam, ich weiss, weshalb ich von MySQL vor über 10
Jahren weggegangen bin!

PostgreSQL arbeitet typsicher, d.h. man kann das nicht einfach so
machen:

#v+
> select length(123456789);
ERROR:  function length(integer) does not exist
LINE 1: select length(123456789);
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
#v-

Es geht schon auf diese Weise, aber dazu muss man explizit den
Typwechsel vornehmen, also:

#v+
> select length(123456789::varchar);
 length
--------
      9
(1 row)
#v-

Einfacher und IMO wesentlich konsistenter ist aber eine
Integer-Division.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Prunkvoll bleibt prunkvoll: Doch Stefan hilft!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#569170

Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:

> On Sun, 02 Oct 2022 20:44:41 Goetz Schultz wrote:
>> On 02/10/2022 19:39, Stefan Ram wrote:
>>> Goetz Schultz <news.expire1225@goetz.co.uk> writes:
>>>> In einem SELECT-Statement ist eines der Felder ein BigInt. Ich
>>>> moechte von dem BigInt-wert die letzten beiden Ziffern wegfallen
>>>> lassen (also statt 10 nur 8 Ziffern). Geht das mit Bordmitteln
>>>> (Skripten /nach/ der Ausgabe geht, ist aber suboptimal).
>
> [F == 123456789]
>>> |mysql> SELECT LEFT(F,LENGTH(F)-2) FROM T;
>>> |+---------------------+
>>> || LEFT(F,LENGTH(F)-2) |
>>> |+---------------------+
>>> || 1234567             |
>>> |+---------------------+
>>> |1 row in set (0.00 sec)
>
>> Ah, das sieht schon mal gut aus. Sollte auch mit PSQL gehen .....
>
> Das ist *so* grausam, ich weiss, weshalb ich von MySQL vor über 10
> Jahren weggegangen bin!

Das sieht aus wie PHP. 11 + 1 = 111, manchmal.


-- 
"Die Abwesenheit von Evidenz zur Wirksamkeit ist keine Evidenz 
für die Abwesenheit von Wirksamkeit."
 - Der Grünen-Gesundheitsexperte Janosch Dahmen.

[toc] | [prev] | [next] | [standalone]

#569179

On Mon, 03 Oct 2022 11:39:14 Stefan Ram wrote:
> Michael Bode <m.g.bode@web.de> writes:
>>Das sieht aus wie PHP. 11 + 1 = 111, manchmal.

> Ich glaube, die Datentypenlässigkeit wird in MySQL
> so erklärt, daß Typprüfungen von höheren Schichten
> durchgeführt werden (können) und in der Datenbank-
> schicht nicht noch einmal wiederholt werden brauchen.

Irgend so etwas habe ich auch im Hinterkopf, ja. Es klappt in der
Praxis halt nicht: Einmal denkt sich - so wie hier jemand - dass das
ja eigentlich praktisch ist und verwendet das "Feature" ganz
bewusst, ein anderes Mal irrt sich jemand schlicht und ergreifend.

Dann kommt ein Feature-Request, der Datentyp eines Attributs
wechselt, an -zig Abfragen denkt keiner und es passiert beliebiges,
BTDT.

Eine Datenbank ist das Rückgrat (wenigstens) einer Applikation, und
ich habe es sehr zu schätzen gelernt, wenn mir im Fehlerfall bereits
*dort* alles *sofort* um die Ohren fliegt und nicht erst - je nach
Eingangsdaten irgendwann später an irgendeiner ganz anderen Stelle.

> In meinem ersten SQL-Kurs wollte ich ja PostgreSQL verwenden.  Ich
> stieg auf MySQL um, nachdem die übergroße Mehrheit der
> Kursteilnehmer sich dies so gewünscht hat.

Das wundert mich nicht, MySQL ist einfach unglaublich populär, auch
in gängiger OS-Software, und jeder lernt gerne das, was er selber
verwendet.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - der maskiertste Witz seit der Steinzeit.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#569181

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Michael Bode <m.g.bode@web.de> writes:
>>Das sieht aus wie PHP. 11 + 1 = 111, manchmal.
>
>   Ich glaube, die Datentypenlässigkeit wird in MySQL
>   so erklärt, daß Typprüfungen von höheren Schichten
>   durchgeführt werden (können) und in der Datenbank-
>   schicht nicht noch einmal wiederholt werden brauchen.

Ich hab ne Weile in Ada programmiert. Da kriege ich von sowas Plaque.

-- 
"Die Abwesenheit von Evidenz zur Wirksamkeit ist keine Evidenz 
für die Abwesenheit von Wirksamkeit."
 - Der Grünen-Gesundheitsexperte Janosch Dahmen.

[toc] | [prev] | [standalone]

Back to top | Article view | ger.ct

csiph-web