POSTGRESQL BUG REPORT TEMPLATE
Your name : Krzysztof Gajdemski
Your email address : [EMAIL PROT
Krzysztof Gajdemski <[EMAIL PROTECTED]> writes:
> PostgreSQL version (example: PostgreSQL-7.1): PostgreSQL-7.1rc4
> query doesn't produce reliable results for some specific circumstances
I tried your example in current sources and get reasonable-looking
behavior:
regression=# SELECT nick F
[EMAIL PROTECTED] writes:
> The query does an avg on an interval column and now gets the error:
> ERROR: Bad interval external representation '0'
Sorry about that :-(. A last-minute tightening of the allowed input
formats for interval broke avg(interval), but you're the first one to
notice.
I
18.05.2001, 11:12:27, Tom Lane wrote:
> Krzysztof Gajdemski <[EMAIL PROTECTED]> writes:
> > PostgreSQL version (example: PostgreSQL-7.1): PostgreSQL-7.1rc4
>
> > query doesn't produce reliable results for some specific circumstances
>
> I tried your example in current sources and get reason
Christoph Lorenz ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
select avg() and sum() returns false value
Long Description
I don't know, if it's my fault, but when I sum up several thousands
of positive entries in a column (t
[EMAIL PROTECTED] writes:
> I don't know, if it's my fault, but when I sum up several thousands
> of positive entries in a column (the column is an int2 field), I get a negative(!)
>value.
Use Postgres 7.1.
regards, tom lane
---(end of broadcast)
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> We have recently upgraded from 7.0.3 to 7.1 and a query which used
>> to work is no longer working.
>> The query does an avg on an interval column and now gets the error:
>> ERROR: Bad interval external representation '0'
> OK, there is one case of
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> I suggest that the current code is more correct than you think ;-).
>> ISTM it is a good idea to require a units field, or at least some
>> punctuation giving a clue about units --- for example I do not object to
>> '08:00' being interpreted as hours