Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 0a54b78

Browse files
bmomjianbmomjian
committed
Add type conversion discussion.
1 parent 42c3381 commit 0a54b78

File tree

1 file changed

+158
-1
lines changed

1 file changed

+158
-1
lines changed

‎doc/TODO.detail/typeconv

Lines changed: 158 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -122,7 +122,7 @@ From [email protected] Sun May 14 17:30:56 2000
122122
Received: from renoir.op.net ([email protected] [207.29.195.4])
123123
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA05808
124124
for <[email protected]>; Sun, 14 May 2000 17:30:52 -0400 (EDT)
125-
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.3 $) with ESMTP id RAA16657 for <[email protected]>; Sun, 14 May 2000 17:29:52 -0400 (EDT)
125+
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.4 $) with ESMTP id RAA16657 for <[email protected]>; Sun, 14 May 2000 17:29:52 -0400 (EDT)
126126
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
127127
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA20914;
128128
Sun, 14 May 2000 17:29:30 -0400 (EDT)
@@ -757,3 +757,160 @@ Comments?
757757

758758
regards, tom lane
759759

760+
From [email protected] Sat Dec 29 15:47:47 2001
761+
Return-path: <[email protected]>
762+
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
763+
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fBTKlkT05111
764+
for <[email protected]>; Sat, 29 Dec 2001 15:47:46 -0500 (EST)
765+
Received: from postgresql.org (postgresql.org [64.49.215.8])
766+
by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fBTKhZN74322
767+
for <[email protected]>; Sat, 29 Dec 2001 14:43:35 -0600 (CST)
768+
(envelope-from [email protected])
769+
Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35])
770+
by postgresql.org (8.11.3/8.11.4) with ESMTP id fBTKaem38452
771+
for <[email protected]>; Sat, 29 Dec 2001 15:36:40 -0500 (EST)
772+
(envelope-from [email protected])
773+
Received: (from pgman@localhost)
774+
by candle.pha.pa.us (8.11.6/8.10.1) id fBTKaTg04256;
775+
Sat, 29 Dec 2001 15:36:29 -0500 (EST)
776+
From: Bruce Momjian <[email protected]>
777+
Message-ID: <[email protected]>
778+
Subject: Re: [GENERAL] Casting Varchar to Numeric
779+
In-Reply-To: <[email protected]>
780+
To: Stephan Szabo <[email protected]>
781+
Date: Sat, 29 Dec 2001 15:36:29 -0500 (EST)
782+
cc: Andy Marden <[email protected]>, [email protected]
783+
X-Mailer: ELM [version 2.4ME+ PL96 (25)]
784+
MIME-Version: 1.0
785+
Content-Transfer-Encoding: 7bit
786+
Content-Type: text/plain; charset=US-ASCII
787+
Precedence: bulk
788+
Sender: [email protected]
789+
Status: OR
790+
791+
> On Mon, 3 Dec 2001, Andy Marden wrote:
792+
>
793+
> > Martijn,
794+
> >
795+
> > It does work (believe it or not). I've now tried the method you mention
796+
> > below - that also works and is much nicer. I can't believe that PostgreSQL
797+
> > can't work this out. Surely implementing an algorithm that understands that
798+
> > if you can go from a ->b and b->c then you can certainly go from a->c. If
799+
>
800+
> It's more complicated than that (and postgres does some of this but not
801+
> all), for example the cast text->float8->numeric potentially loses
802+
> precision and should probably not be an automatic cast for that reason.
803+
>
804+
> > this is viewed as too complex a task for the internals - at least a diagram
805+
> > or some way of understanding how you should go from a->c would be immensely
806+
> > helpful wouldn't it! Daunting for anyone picking up the database and trying
807+
> > to do something simple(!)
808+
>
809+
> There may be a need for documentation on this. Would you like to write
810+
> some ;)
811+
812+
OK, I ran some tests:
813+
814+
test=> create table test (x text);
815+
CREATE
816+
test=> insert into test values ('323');
817+
INSERT 5122745 1
818+
test=> select cast (x as numeric) from test;
819+
ERROR: Cannot cast type 'text' to 'numeric'
820+
821+
I can see problems with automatically casting numeric to text because
822+
you have to guess the desired format, but going from text to numeric
823+
seems quite easy to do. Is there a reason we don't do it?
824+
825+
I can cast to integer and float8 fine:
826+
827+
test=> select cast ( x as integer) from test;
828+
?column?
829+
----------
830+
323
831+
(1 row)
832+
833+
test=> select cast ( x as float8) from test;
834+
?column?
835+
----------
836+
323
837+
(1 row)
838+
839+
--
840+
Bruce Momjian | http://candle.pha.pa.us
841+
[email protected] | (610) 853-3000
842+
+ If your life is a hard drive, | 830 Blythe Avenue
843+
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
844+
845+
---------------------------(end of broadcast)---------------------------
846+
TIP 2: you can get off all lists at once with the unregister command
847+
(send "unregister YourEmailAddressHere" to [email protected])
848+
849+
From [email protected] Sat Dec 29 19:10:38 2001
850+
Return-path: <[email protected]>
851+
Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
852+
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fBU0AbT23972
853+
for <[email protected]>; Sat, 29 Dec 2001 19:10:37 -0500 (EST)
854+
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
855+
by west.navpoint.com (8.11.6/8.10.1) with ESMTP id fBTNVj008959
856+
for <[email protected]>; Sat, 29 Dec 2001 18:31:45 -0500 (EST)
857+
Received: from postgresql.org (postgresql.org [64.49.215.8])
858+
by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fBTNQrN78655
859+
for <[email protected]>; Sat, 29 Dec 2001 17:26:53 -0600 (CST)
860+
(envelope-from [email protected])
861+
Received: from sss.pgh.pa.us ([192.204.191.242])
862+
by postgresql.org (8.11.3/8.11.4) with ESMTP id fBTN8Fm47978
863+
for <[email protected]>; Sat, 29 Dec 2001 18:08:15 -0500 (EST)
864+
(envelope-from [email protected])
865+
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
866+
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id fBTN7vg20245;
867+
Sat, 29 Dec 2001 18:07:57 -0500 (EST)
868+
To: Bruce Momjian <[email protected]>
869+
cc: Stephan Szabo <[email protected]>,
870+
Andy Marden <[email protected]>, [email protected]
871+
Subject: Re: [GENERAL] Casting Varchar to Numeric
872+
In-Reply-To: <[email protected]>
873+
References: <[email protected]>
874+
Comments: In-reply-to Bruce Momjian <[email protected]>
875+
message dated "Sat, 29 Dec 2001 15:36:29 -0500"
876+
Date: Sat, 29 Dec 2001 18:07:57 -0500
877+
Message-ID: <[email protected]>
878+
From: Tom Lane <[email protected]>
879+
Precedence: bulk
880+
Sender: [email protected]
881+
Status: OR
882+
883+
Bruce Momjian <[email protected]> writes:
884+
> I can see problems with automatically casting numeric to text because
885+
> you have to guess the desired format, but going from text to numeric
886+
> seems quite easy to do. Is there a reason we don't do it?
887+
888+
I do not think it's a good idea to have implicit casts between text and
889+
everything under the sun, because that essentially destroys the type
890+
checking system. What we need (see previous discussion) is a flag in
891+
pg_proc that says whether a type conversion function may be invoked
892+
implicitly or not. I've got no problem with offering text(numeric) and
893+
numeric(text) functions that are invoked by explicit function calls or
894+
casts --- I just don't want the system trying to use them to make
895+
sense of a bogus query.
896+
897+
> I can cast to integer and float8 fine:
898+
899+
I don't believe that those should be available as implicit casts either.
900+
They are, at the moment:
901+
902+
regression=# select 33 || 44.0;
903+
?column?
904+
----------
905+
3344
906+
(1 row)
907+
908+
Ugh.
909+
910+
regards, tom lane
911+
912+
---------------------------(end of broadcast)---------------------------
913+
TIP 6: Have you searched our list archives?
914+
915+
http://archives.postgresql.org
916+

0 commit comments

Comments
 (0)