From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
---|---|
To: | martin(dot)wuertele(at)factline(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: timestamp handling in postgres 7.1 behaves strange |
Date: | 2001-08-09 00:10:01 |
Message-ID: | 3B71D4D9.E82853E8@fourpalms.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> when comparing timestamps i always get
> ERROR: Bad timestamp external representation 'm'
> this works:
> select timestamp (content) from factversionelement where factid=100311 and elementname='newsdate';
> ------------------------
> 2010-01-02 16:00:00+01
> this does not:
> select factid from factversionelement where factid=100311 and elementname='newsdate' and timestamp (content) >= '2001-08-08';
> ERROR: Bad timestamp external representation 'm'
In the first case, you are evaluating the timestamp only after the
"where qualifications" are met, so this is done on one row. In the
second case, the optimizer is probably having you evaluate
timestamp(content) ON ALL ROWS as the first pass. At least one of those
rows has a value which is incompatible with timestamp data.
Please state the schema of the factversionelement table. I will bet that
the "content" column is not in fact a timestamp type (it is some sort of
string type??), and does not contain strings which are entirely legal as
timestamps.
- Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-08-09 02:14:53 | Re: timestamp handling in postgres 7.1 behaves strange |
Previous Message | pgsql-bugs | 2001-08-08 22:44:20 | timestamp handling in postgres 7.1 behaves strange |