>> but again to_date doesn't:
>>
>> regression=# select to_date('4714-01-27 BC', '-MM-DD BC');
>> to_date
>> ---
>> 4714-01-27 BC
>> (1 row)
>>
>
> I'm not concerned about to_date so much as I am that timestamp_in lets you
> store values you can't read with timestamp_out. O
>
> postgres=# select '4714-01-27 BC'::date;
> ERROR: date out of range: "4714-01-27 BC"
> postgres=# select cast(test as date) from timetest;
> test
> ---
> 4714-01-27 BC
> (1 row)
>
> postgres=#
> postgres=# select cast('4714-01-27 BC' as date);
> ERROR: date out of range: "
Robert Treat <[EMAIL PROTECTED]> writes:
> I'm not concerned about to_date so much as I am that timestamp_in lets you
> store values you can't read with timestamp_out.
Your example does not demonstrate any such thing. What it demonstrates
is that to_date will let an out-of-range date into the sy
On Thursday 02 November 2006 17:48, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > pagila=# select to_date('3232098', 'MM/DD/');
> > to_date
> > ---
> > 4568-06-26 BC
> > (1 row)
>
> to_date's absymal lack of error checking is well known. It should
> surely ref
Robert Treat <[EMAIL PROTECTED]> writes:
> pagila=# select to_date('3232098', 'MM/DD/');
> to_date
> ---
> 4568-06-26 BC
> (1 row)
to_date's absymal lack of error checking is well known. It should
surely refuse that input altogether, given that format string.
Feel free to sen
We found the problem on one of our production 8.1 servers; a big concern is
that it breaks dumps (allows you to dump a table with a value that can't be
restored). Seems to be a problem in 8.2 as well. Here is the test case:
pagila=# create table t1 (c1 timestamp);
CREATE TABLE
pagila=# select
