From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
---|---|
To: | Lutz Horn <lutz(dot)horn(at)posteo(dot)de> |
Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Select "todays" timestamps in an index friendly way |
Date: | 2018-10-23 17:00:39 |
Message-ID: | CA+bJJbx8mT0DF+y5YrtEDLwBhJ=5kTg7N2dNbBnnq5CUmaH=dg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Oct 23, 2018 at 3:57 PM, Lutz Horn <lutz(dot)horn(at)posteo(dot)de> wrote:
> On Tue, Oct 23, 2018 at 03:50:14PM +0200, Francisco Olarte wrote:
>> It'is not as the problem was stated. Although ts defaulted to now(),
>> and it is probably defaulted, nothing prohibits him from inserting
>> timestamps in the future.
> Yes, this table is only used as an example for the technical question.
> In my real use case there are columns like "due_date" which usually
> contain future dates inserted by application code.
If your real table uses dates instead of timestamps modify the code
accordingly, they are not the same ( dates are countable, instants in
time are not (they are in the computer, with finite precision, but you
see the difference )) Although I supose they really are timestamps, or
you would have just used "date_column=current_date".
>> the "timestamps in today" pattern is commonly used in calendaring
>> applications, which usually insert appointments in the future and
>> recover this way to print "todays schedule".
> Exactly. The application must be able to execute queries like "give me
> all my tasks due today" without having to use a concrete value for
> "today".
Been there, done that. With an IBM 84 ( instructional use. It was, not
surprissingly, easier but slower, ).
Happy hacking.
Francisco Olarte.
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Rylander | 2018-10-23 18:14:04 | Re: Select "todays" timestamps in an index friendly way |
Previous Message | Boris Sagadin | 2018-10-23 16:28:54 | Re: Postgres 10, slave not catching up with master |