On Mon, Feb 28, 2011 at 02:04:53PM -0500, Robert Haas wrote:
> On Sun, Feb 27, 2011 at 1:39 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Tue, Feb 8, 2011 at 5:04 PM, Josh Berkus wrote:
> >>> I'm not saying that PostgreSQL couldn't do better on this kind of case,
> >>> but that doing bette
On Sun, Feb 27, 2011 at 1:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 8, 2011 at 5:04 PM, Josh Berkus wrote:
>>> I'm not saying that PostgreSQL couldn't do better on this kind of case,
>>> but that doing better is a major project, not a minor one.
>
>> Specifically, the problem i
Robert Haas writes:
> On Tue, Feb 8, 2011 at 5:04 PM, Josh Berkus wrote:
>> I'm not saying that PostgreSQL couldn't do better on this kind of case,
>> but that doing better is a major project, not a minor one.
> Specifically, the problem is that x = 4.0, where x is an integer, is
> defined to me
On Tue, Feb 8, 2011 at 5:04 PM, Josh Berkus wrote:
> Laszlo,
>
>> Which is silly. I think that PostgreSQL converts the int side to a
>> float, and then compares them.
>>
>> It would be better to do this, for each item in the loop:
>>
>> * evaluate the right side (which is float)
>> * tell
09.02.11 01:14, Dave Crooke написав(ла):
You will get the same behaviour from any database product where the
query as written requires type coercion - the coercion has to go in
the direction of the "wider" type. I have seen the exact same scenario
with Oracle, and I view it as a problem with th
You will get the same behaviour from any database product where the query as
written requires type coercion - the coercion has to go in the direction of
the "wider" type. I have seen the exact same scenario with Oracle, and I
view it as a problem with the way the query is written, not with the
data
Laszlo,
> Which is silly. I think that PostgreSQL converts the int side to a
> float, and then compares them.
>
> It would be better to do this, for each item in the loop:
>
> * evaluate the right side (which is float)
> * tell if it is an integer or not
> * if not an integer, then d
This query:
select p.id,p.producer_id,visa.variation_item_id, vi.qtyavail
from variation_item_sellingsite_asin visa
inner join product p on p.id = visa.product_id
inner join variation_item vi on vi.id =
visa.var
