Implizite lossy Typecasts bei INSERTs

Hallo,

mir fiel neulich auf, dass:

| tim=3D# SELECT version();
| version
| ------------------------------------------------------------ -------------=
------------------------------
| PostgreSQL 8.3.5 on i386-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.3=
..2 20081007 (Red Hat 4.3.2-6)
| (1 Zeile)
|
| tim=3D# CREATE TABLE Test (i INT);
| CREATE TABLE
| tim=3D# INSERT INTO Test (i) VALUES (3.1415);
| INSERT 0 1
| tim=3D# SELECT * FROM Test;
| i
| ---
| 3
| (1 Zeile)
|
| tim=3D#

ohne Fehlermeldung durchläuft. Irgendwo in meinem Gedächtnis
schlummert die Erinnerung, dass das früher anders war. Ehe
ich die release notes der letzten Jahre noch einmal durchge-
he :-): War das wirklich jemals anders?

Danke,
Tim

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: Implizite lossy Typecasts bei INSERTs

Hallo,

On Fri, 26 Dec 2008 17:48:19 +0000 Tim Landscheidt wrote:

> mir fiel neulich auf, dass:
>=20
> | tim=3D# SELECT version();
> | version
> | ------------------------------------------------------------ -----------=
--------------------------------
> | PostgreSQL 8.3.5 on i386-redhat-linux-gnu, compiled by GCC gcc (GCC) 4=
..3.2 20081007 (Red Hat 4.3.2-6)
> | (1 Zeile)
> |
> | tim=3D# CREATE TABLE Test (i INT);
> | CREATE TABLE
> | tim=3D# INSERT INTO Test (i) VALUES (3.1415);
> | INSERT 0 1
> | tim=3D# SELECT * FROM Test;
> | i
> | ---
> | 3
> | (1 Zeile)
> |
> | tim=3D#
>=20
> ohne Fehlermeldung durchläuft. Irgendwo in meinem Gedächtnis
> schlummert die Erinnerung, dass das früher anders war.

Nicht das ich wüsste aber ich habe es eben mal auf einer 7.4
ausprobiert und dort funktioniert das wie oben gepastet.

Da hat sich also nichts geändert. Was allerdings auf einer 7.4 und
einer 8.3 nicht funktioniert:

test=3D# insert into test (i) values ('3.1415');
ERROR: invalid input syntax for integer: "3.1415"


Schönen Abend noch

--=20
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: Implizite lossy Typecasts bei INSERTs

On Friday 26 December 2008 19:48:19 Tim Landscheidt wrote:
> Hallo,
>
> mir fiel neulich auf, dass:
> | tim=3D# SELECT version();
> | version
> | ------------------------------------------------------------ -----------=
--
> |------------------------------ PostgreSQL 8.3.5 on i386-redhat-linux-gnu,
> | compiled by GCC gcc (GCC) 4.3.2 20081007 (Red Hat 4.3.2-6) (1 Zeile)
> |
> | tim=3D# CREATE TABLE Test (i INT);
> | CREATE TABLE
> | tim=3D# INSERT INTO Test (i) VALUES (3.1415);
> | INSERT 0 1
> | tim=3D# SELECT * FROM Test;
> | i
> | ---
> | 3
> | (1 Zeile)
> |
> | tim=3D#
>
> ohne Fehlermeldung durchläuft. Irgendwo in meinem Gedächtnis
> schlummert die Erinnerung, dass das früher anders war. Ehe
> ich die release notes der letzten Jahre noch einmal durchge-
> he :-): War das wirklich jemals anders?

Nur mal um das Verständnis vielleicht zu verbessern: Obiger Fall ist=20
kein "impliziter" Typecast im Sinne von CREATE CAST ... AS IMPLICIT, sonder=
n=20
AS ASSIGNMENT, weil hier die Zuweisung eines Wertes in einen Speicherort mi=
t=20
festgelegtem Typ stattfindet. Implizite Typecasts, die "lossy" sind, sollt=
e=20
es nicht geben (zumindest in neueren Versionen), aber im Fall AS ASSIGNMENT=
=20
kann das schon vorkommen, hauptsächlich, wenn der SQL-Standard danach=20
verlangt.

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: Implizite lossy Typecasts bei INSERTs

Peter Eisentraut wrote:

>> mir fiel neulich auf, dass:
>> | tim=3D# SELECT version();
>> | version
>> | ------------------------------------------------------------ ----------=
---
>> |------------------------------ PostgreSQL 8.3.5 on i386-redhat-linux-gn=
u,
>> | compiled by GCC gcc (GCC) 4.3.2 20081007 (Red Hat 4.3.2-6) (1 Zeile)
>> |
>> | tim=3D# CREATE TABLE Test (i INT);
>> | CREATE TABLE
>> | tim=3D# INSERT INTO Test (i) VALUES (3.1415);
>> | INSERT 0 1
>> | tim=3D# SELECT * FROM Test;
>> | i
>> | ---
>> | 3
>> | (1 Zeile)
>> |
>> | tim=3D#

>> ohne Fehlermeldung durchläuft. Irgendwo in meinem Gedächtnis
>> schlummert die Erinnerung, dass das früher anders war. Ehe
>> ich die release notes der letzten Jahre noch einmal durchge-
>> he :-): War das wirklich jemals anders?

> Nur mal um das Verständnis vielleicht zu verbessern: Obiger Fall ist
> kein "impliziter" Typecast im Sinne von CREATE CAST ... AS IMPLICIT, sond=
ern
> AS ASSIGNMENT, weil hier die Zuweisung eines Wertes in einen Speicherort =
mit
> festgelegtem Typ stattfindet. Implizite Typecasts, die "lossy" sind, sol=
lte
> es nicht geben (zumindest in neueren Versionen), aber im Fall AS ASSIGNME=
NT
> kann das schon vorkommen, hauptsächlich, wenn der SQL-Standard danach
> verlangt.

Danke für die Erläuterung (und Andreas für den Test). Das
"implizit" bezog sich auch nur auf die Anwendersicht (es er-
innerte mich an unschöne Erfahrungen mit dem Import von Ka-
lenderdaten früher - da hat es auch jedes Datum implizit
konvertiert :-)).

Aber wenn es Teil des Standards ist, werde ich wohl damit
leben müssen.

Tim

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein