> On Oct 20, 2025, at 5:05 AM, Peter J. Holzer <hjp-pgsql@hjp.at> wrote:
>
> On 2025-10-19 20:32:07 -0600, Rob Sargent wrote:
>>>> On Oct 19, 2025, at 2:38 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
>>> On Sun, 19 Oct 2025, Rob Sargent wrote:
>>>> I think you have to ask why those values were separated in the first
>>>> place. For instance if they are thought of as a pair in most queries then
>>>> an alteration might be in order. There can be a large one time cost if
>>>> these tables occur in a lot of separate sql calls in the business logic.
>>>
>>> Good point. They're in the contacts table and I use them to determine when
>>> to make another contact and if prior contacts were more productive in the
>>> morning or afternoon.
>>
>> Definitely a datetime (single value) problem, imho
>
> Actually, to me that seems to be one of the few cases where splitting
> them makes sense. I would expect typical updates to be something like
> "sane time, but 6 months later" or "same day, but different time". There
> might also be constraints like "not before 9am". For queries there might
> be stuff like "who do I need to call today", or as Rich already
> mentioned, statistics by time of the day. There are probably relatively
> few queries where you need to treat date and time as a unit.
>
> hjp
I don’t see any mention of the current data types of the two columns currently in play. apologies of I missed that.
Which of your example updates cannot be done with timestamp? Perhaps the “not before”constraint but can that be done
withOP’s design? Maybe the time column is an interval?
>
> --
> _ | Peter J. Holzer | Story must make more sense than reality.
> |_|_) | |
> | | | hjp@hjp.at | -- Charles Stross, "Creative writing
> __/ | http://www.hjp.at/ | challenge!"
> <signature.asc>
