On Tue, Oct 23, 2018 at 3:57 PM, Lutz Horn <lutz.horn@xxxxxxxxx> 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.
