Re: Bug Repoprt- Casting Issues - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Bug Repoprt- Casting Issues
Date
Msg-id 13961.959926686@sss.pgh.pa.us
Whole thread Raw
In response to Bug Repoprt- Casting Issues  (Dirk Elmendorf <delmendo@rackspace.com>)
Responses Re: Bug Repoprt- Casting Issues  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-bugs
Dirk Elmendorf <delmendo@rackspace.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

pgsql-bugs by date:

Previous
From: Dirk Elmendorf
Date:
Subject: Bug Repoprt- Casting Issues
Next
From: guenther mair
Date:
Subject: double dumps for all objects with pg_dump