From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dirk Elmendorf <delmendo(at)rackspace(dot)com> |
Cc: | bugs(at)postgresql(dot)org |
Subject: | Re: Bug Repoprt- Casting Issues |
Date: | 2000-06-02 06:18:06 |
Message-ID: | 13961.959926686@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Dirk Elmendorf <delmendo(at)rackspace(dot)com> writes:
> insert into test (seconds) values(951414912);
> select seconds::date from test;
> ERROR: Cannot casty type 'int4' to 'date'
> select date(seconds) from test;
> date
> --------
> 200-02-24
I don't think this is a bug, actually. The foo::type notation is
by design stricter than type(foo) --- the :: form will only succeed
when there is a *direct* one-step conversion between the source and
target types, whereas type(foo) will succeed if the parser can find
any way of converting foo to something that any available type()
converter will take.
In this example there is no int4-to-date function, and the path you
are actually taking is
regression=# select 951414912::int4::abstime::date;
?column?
------------
2000-02-24
(1 row)
If you'd prefer not to be concerned about the intermediate conversion to
abstime, then use the date() notation. The :: notation is designed
for controlling the type conversion exactly.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-06-02 14:56:40 | Re: [BUGS] double dumps for all objects with pg_dump |
Previous Message | Bruce Momjian | 2000-06-01 23:36:01 | Re: INET operators and NOT |