Re: An Enigma of a weird query problem - Mailing list pgsql-general

From pythonista
Subject Re: An Enigma of a weird query problem
Date
Msg-id c28aa3d1-69a5-45e8-b734-cf01560c1545@e34g2000pra.googlegroups.com
Whole thread Raw
List pgsql-general
Sorry, nevermind, the second query returns the correct results.

 It first resolves the inner query to a single date, and then gets all
records matching that date.

On Jun 17, 6:25 am, pythonista <sitecontac...@gmail.com> wrote:
> Hi, I'm new:
>
> This table is called rssitem.   Given the fields:
>
> str_key(varchar)    sent (bool)   date_to_resend(timestamp)  user_id
> ------------------------------------------------------------------------------------------------
> 45rtuu3433ff  False   2010-06-17 01:50:00-05   58 -- first 2 recs
> trtwweddasa  True     2010-06-17 01:50:00-05   58 -- have same
> datetime
> gggggtterere  False   2010-06-18 01:50:00-35   58
> aaaadddddd  False   2010-06-19 01:50:00-45   58
>
> (The str_key is the primary key. It's actually a unique hash value,
> and it's unrelated to the issue, just explaining.)
>
> Sooo... First, a query that returns the correct result:
>
>     select min(date_to_resend) from rssitem where sent = False and
> user_id = 58
>
>    Returns:  "2010-06-16 05:39:00-05" ,   successfully matching the
> very first record.
>
> However, this query (which uses the first query in a subquery)
>
> select str_key, sent,date_to_resend from rssitem where date_to_resend
> IN
>       (select min(date_to_resend) from rssitem where sent = False and
> user_id = 58)
>
> Returns the first record which is correct, but the second record does
> not belong, due to sent = True
>
> 45rtuu3433ff    FALSE   2010-06-17 01:50:00-05    58
> trtwweddasa   TRUE      2010-06-17 01:50:00-05    58
>
> Might this be a bug?  I can't just wrap my brain around it


pgsql-general by date:

Previous
From: "Marvin S. Addison"
Date:
Subject: Excessive Deadlocks On Concurrent Inserts to Shared Parent Row
Next
From: Ozz Nixon
Date:
Subject: UUID/GUID