From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Chuck Martin <clmartin(at)theombudsman(dot)com> |
Cc: | Francisco Olarte <folarte(at)peoplecall(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Query not producing expected result |
Date: | 2019-05-01 17:50:16 |
Message-ID: | 27a5b2e7-9e84-ab43-68a3-d5009e5815a0@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 5/1/19 10:37 AM, Chuck Martin wrote:
> Something like daterange would be a solution in some circumstances, but
> this query is a user-generated one, and they don't have that much
> control over the query. It has to be modified as needed behind the
> scenes so that it produces the results they expect. In this instance,
> I'm now (given the advice received here) inclined to check the value
> entered when searching for a date, and if no time is entered, add
> '24:00' to the date.
I should have made it clearer, my suggestion was mostly directed at
Franciso's example.
Still:
select tsrange('2019-05-01', '2019-05-02') @> '2019-05-01 9:52'::timestamp;
?column?
----------
t
If you are modifying anyway:)
For this sort of thing, I have found range types to be a time and sanity
saver. Just throwing it out there.
>
> Chuck Martin
> Avondale Software
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Olarte | 2019-05-01 17:51:40 | Re: Query not producing expected result |
Previous Message | Francisco Olarte | 2019-05-01 17:41:30 | Re: Query not producing expected result |