> On Oct 23, 2025, at 1:52 PM, Peter J. Holzer wrote:
>
> On 2025-10-20 06:43:17 -0600, Rob Sargent wrote:
>>
>>
On Oct 20, 2025, at 5:05 AM, Peter J. Holzer wrote:
>>>
>>> On 2025-10-19 20:32:07 -0600, Rob Sargent wrote:
>> On Oct 19, 2025, at 2:38 PM, Rich Shepard
>> wro
On 2025-10-20 06:43:17 -0600, Rob Sargent wrote:
>
>
> > On Oct 20, 2025, at 5:05 AM, Peter J. Holzer wrote:
> >
> > On 2025-10-19 20:32:07 -0600, Rob Sargent wrote:
> On Oct 19, 2025, at 2:38 PM, Rich Shepard
> wrote:
> >>> On Sun, 19 Oct 2025, Rob Sargent wrote:
> I think yo
> On Oct 20, 2025, at 6:58 AM, Rich Shepard wrote:
>
> On Mon, 20 Oct 2025, Rob Sargent wrote:
>
>>> Okay. Now I'm curious: why do you write this?
>
>> The way I read your description of how you use these columns currently
>> suggests to me that they could be handled by a single timestamp c
On Mon, Oct 20, 2025 at 8:58 AM Rich Shepard
wrote:
> On Mon, 20 Oct 2025, Rob Sargent wrote:
>
> >> Okay. Now I'm curious: why do you write this?
>
> > The way I read your description of how you use these columns currently
> > suggests to me that they could be handled by a single timestamp colum
On Mon, 20 Oct 2025, Rob Sargent wrote:
Okay. Now I'm curious: why do you write this?
The way I read your description of how you use these columns currently
suggests to me that they could be handled by a single timestamp column.
The cost/benefit of converting is another thing altogether.
Ro
> On Oct 20, 2025, at 6:45 AM, Rich Shepard wrote:
>
> On Sun, 19 Oct 2025, Rob Sargent wrote:
>
>> Definitely a datetime (single value) problem, imho
>
> Rob,
>
> Okay. Now I'm curious: why do you write this?
>
> Thanks,
>
> Rich
>
The way I read your description of how you use these
On Mon, 20 Oct 2025, Rob Sargent wrote:
I don’t see any mention of the current data types of the two columns
currently in play. apologies of I missed that.
Column| Type | Collation | Nullable | Default
--++---+-
On Sun, 19 Oct 2025, Rob Sargent wrote:
Definitely a datetime (single value) problem, imho
Rob,
Okay. Now I'm curious: why do you write this?
Thanks,
Rich
> On Oct 20, 2025, at 5:05 AM, Peter J. Holzer wrote:
>
> On 2025-10-19 20:32:07 -0600, Rob Sargent wrote:
On Oct 19, 2025, at 2:38 PM, Rich Shepard wrote:
>>> On Sun, 19 Oct 2025, Rob Sargent wrote:
I think you have to ask why those values were separated in the first
place. F
On 2025-10-19 20:32:07 -0600, Rob Sargent wrote:
> > On Oct 19, 2025, at 2:38 PM, Rich Shepard 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
> On Oct 19, 2025, at 2:38 PM, Rich Shepard 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
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 sq
> On Oct 19, 2025, at 1:08 PM, Rich Shepard wrote:
>
> On Sun, 19 Oct 2025, Laurenz Albe wrote:
>
>> That depends on what you do with the table.
>
> Laurenz,
>
> That makes sense.
>
>> Are your SQL statements simple and natural with the current design?
>> Then stick with what you have now
On Sun, 19 Oct 2025, Laurenz Albe wrote:
That depends on what you do with the table.
Laurenz,
That makes sense.
Are your SQL statements simple and natural with the current design?
Then stick with what you have now.
That's what I'm going to do. I was curious when a timestamp column was mor
On Sun, 2025-10-19 at 07:43 -0700, Rich Shepard wrote:
> The database has a table with separate date and time columns.
>
> 1. Are there benefits to merging the two into a single timestamp column?
That depends on what you do with the table.
Are your SQL statements simple and natural with the curre
On Sun, 19 Oct 2025, Isaac Morland wrote:
If you're talking about actually changing the table, replacing the two
columns with a single column, you would need ALTER TABLE. Something like
(not tested, just to give you the basic idea):
Issac,
I thought it could be that simple, while I was lookin
On 10/19/25 09:35, Rich Shepard wrote:
On Sun, 19 Oct 2025, Adrian Klaver wrote:
2) If you really need a timestamp the work is already done, instead of
building on the fly.
Adrian,
As each row in the table already has both a date column and a time column I
don't know if I 'really' need a tim
On Sun, 19 Oct 2025 at 12:35, Rich Shepard wrote:
> On Sun, 19 Oct 2025, Adrian Klaver wrote:
>
> > 2) If you really need a timestamp the work is already done, instead of
> > building on the fly.
>
> Adrian,
>
> As each row in the table already has both a date column and a time column I
> don't k
On Sun, 19 Oct 2025, Adrian Klaver wrote:
2) If you really need a timestamp the work is already done, instead of
building on the fly.
Adrian,
As each row in the table already has both a date column and a time column I
don't know if I 'really' need a timestamp. When would a timestamp be really
On 10/19/25 07:53, Adrian Klaver wrote:
On 10/19/25 07:43, Rich Shepard wrote:
The database has a table with separate date and time columns.
1. Are there benefits to merging the two into a single timestamp column?
1) One less column to fetch from.
2) If you really need a timestamp the work i
On 10/19/25 07:43, Rich Shepard wrote:
The database has a table with separate date and time columns.
1. Are there benefits to merging the two into a single timestamp column?
1) One less column to fetch from.
2) If you really need a timestamp the work is already done, instead of
building on t
21 matches
Mail list logo
