Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit0a54b78

Browse files
committed
Add type conversion discussion.
1 parent42c3381 commit0a54b78

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 tgl@sss.pgh.pa.us Sun May 14 17:30:56 2000
122122
Received: from renoir.op.net (root@renoir.op.net [207.29.195.4])
123123
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA05808
124124
for <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 pgsql-general-owner+M18949=candle.pha.pa.us=pgman@postgresql.org Sat Dec 29 15:47:47 2001
761+
Return-path: <pgsql-general-owner+M18949=candle.pha.pa.us=pgman@postgresql.org>
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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; Sat, 29 Dec 2001 14:43:35 -0600 (CST)
768+
(envelope-from pgsql-general-owner+M18949=candle.pha.pa.us=pgman@postgresql.org)
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 <pgsql-general@postgresql.org>; Sat, 29 Dec 2001 15:36:40 -0500 (EST)
772+
(envelope-from pgman@candle.pha.pa.us)
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 <pgman@candle.pha.pa.us>
777+
Message-ID: <200112292036.fBTKaTg04256@candle.pha.pa.us>
778+
Subject: Re: [GENERAL] Casting Varchar to Numeric
779+
In-Reply-To: <20011206150158.O28880-100000@megazone23.bigpanda.com>
780+
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
781+
Date: Sat, 29 Dec 2001 15:36:29 -0500 (EST)
782+
cc: Andy Marden <amarden@usa.net>, pgsql-general@postgresql.org
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: pgsql-general-owner@postgresql.org
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+
pgman@candle.pha.pa.us | (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 majordomo@postgresql.org)
848+
849+
From pgsql-general-owner+M18951=candle.pha.pa.us=pgman@postgresql.org Sat Dec 29 19:10:38 2001
850+
Return-path: <pgsql-general-owner+M18951=candle.pha.pa.us=pgman@postgresql.org>
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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; Sat, 29 Dec 2001 17:26:53 -0600 (CST)
860+
(envelope-from pgsql-general-owner+M18951=candle.pha.pa.us=pgman@postgresql.org)
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 <pgsql-general@postgresql.org>; Sat, 29 Dec 2001 18:08:15 -0500 (EST)
864+
(envelope-from tgl@sss.pgh.pa.us)
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 <pgman@candle.pha.pa.us>
869+
cc: Stephan Szabo <sszabo@megazone23.bigpanda.com>,
870+
Andy Marden <amarden@usa.net>, pgsql-general@postgresql.org
871+
Subject: Re: [GENERAL] Casting Varchar to Numeric
872+
In-Reply-To: <200112292036.fBTKaTg04256@candle.pha.pa.us>
873+
References: <200112292036.fBTKaTg04256@candle.pha.pa.us>
874+
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
875+
message dated "Sat, 29 Dec 2001 15:36:29 -0500"
876+
Date: Sat, 29 Dec 2001 18:07:57 -0500
877+
Message-ID: <20242.1009667277@sss.pgh.pa.us>
878+
From: Tom Lane <tgl@sss.pgh.pa.us>
879+
Precedence: bulk
880+
Sender: pgsql-general-owner@postgresql.org
881+
Status: OR
882+
883+
Bruce Momjian <pgman@candle.pha.pa.us> 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)

[8]ページ先頭

©2009-2025 Movatter.jp