| From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
|---|---|
| To: | Hellmuth Vargas <hivs77(at)gmail(dot)com> |
| Cc: | Thomas Kellerer <spam_eater(at)gmx(dot)net>, "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 13:50:14 |
| Message-ID: | CA+bJJbziH8xXSg+4KsSpiWCyX3ORCvcrxKk_d5SRc95AGWZa8A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Oct 23, 2018 at 3:05 PM, Hellmuth Vargas <hivs77(at)gmail(dot)com> wrote:
...
>> Then use current_date:
>>
>> where ts >= current_date
>> and ts < current_date + 1
>
> this is equally valid?
>
> where ts >= current_date
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.
Also, I'll point the table used in the sample ( bigserial+timestamp)
does not seem like a real one and 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".
Francisco Olarte.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lutz Horn | 2018-10-23 13:57:28 | Re: Select "todays" timestamps in an index friendly way |
| Previous Message | Daniel Fink (PDF) | 2018-10-23 13:24:28 | Enabling bdr in multiple databases on the same postgresql instance/cluster |