Re: Bug Repoprt- Casting Issues

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

In response to

Responses

Browse pgsql-bugs by date

  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