> 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, Ray O'Donnell wrote:
My experience of doing something similar was that arrays work very well
for the use-case you describe, as long as you don't have to search inside
the arrays... I found that, if you have to search for a specific value
inside an array, then performance rea
On Sun, 19 Oct 2025, Adrian Klaver wrote:
For direct_phone and email entries that have more then one value, how do you
know what the values are pointing at e.g home vs office vs second office
location, etc?
Adrian,
At this point I don't know. If there's no answer on one number I try
another.
On 19/10/2025 21:43, Rich Shepard wrote:
In the former book I read that sometimes it's better to have multiple
values
for an atribute in a single row by creating a separate table for that
attribute rather than using the postgres array capability. The people
table
in my database (1706 rows) ha
On 10/19/25 13:43, Rich Shepard wrote:
In the former book I read that sometimes it's better to have multiple
values
for an atribute in a single row by creating a separate table for that
attribute rather than using the postgres array capability. The people table
in my database (1706 rows) has tw
I started developing business and science databases in the mid-1980s using
dBASE III, then Paradox on DOS. I defenestrated in 1997 and have used only
linux for both business and personal needs ever since and using only
PostgreSQL for my databaes (primarily for my own use.) I read Joe Celko's
month
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
The database has a table with separate date and time columns.
1. Are there benefits to merging the two into a single timestamp column?
2. If so, how would I do this? (Reading date/time operators and functions
doc page hasn't shown me one.)
TIA,
Rich
17 matches
Mail list logo
