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

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein
Tim Landscheidt [ Fr, 26 Dezember 2008 18:48 ] [ ID #1982330 ]

Re: Implizite lossy Typecasts bei INSERTs

Hallo,

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

> 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=C3=A4uft. Irgendwo in meinem Ged=C3=A4chtnis
> schlummert die Erinnerung, dass das fr=C3=BCher anders war.

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

Da hat sich also nichts ge=C3=A4ndert. 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=C3=B6nen Abend noch

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

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein
adsmail [ Fr, 26 Dezember 2008 22:17 ] [ ID #1982331 ]

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
kein "impliziter" Typecast im Sinne von CREATE CAST ... AS IMPLICIT, sonder=
n
AS ASSIGNMENT, weil hier die Zuweisung eines Wertes in einen Speicherort mi=
t
festgelegtem Typ stattfindet. Implizite Typecasts, die "lossy" sind, sollt=
e
es nicht geben (zumindest in neueren Versionen), aber im Fall AS ASSIGNMENT=

kann das schon vorkommen, hauptsächlich, wenn der SQL-Standard danach
verlangt.

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein
Peter Eisentraut [ Sa, 27 Dezember 2008 12:28 ] [ ID #1982375 ]

Re: Implizite lossy Typecasts bei INSERTs

Peter Eisentraut <peter_e [at] gmx.net> 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

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein
Tim Landscheidt [ Mo, 29 Dezember 2008 17:23 ] [ ID #1982550 ]
Datenbanken » gmane.comp.db.postgresql.german » Implizite lossy Typecasts bei INSERTs

Vorheriges Thema: == WöchentlicherPostgreSQL Newsletter - 04.Januar 2009
Nächstes Thema: == WöchentlicherPostgreSQL Newsletter - 28.Dezember 2008