From: | "Gregory W Burnham" <gburnham(at)sfu(dot)ca> |
---|---|
To: | "Herouth Maoz" <herouth(at)oumail(dot)openu(dot)ac(dot)il> |
Cc: | <pgsql-interfaces(at)postgreSQL(dot)org> |
Subject: | Re: [INTERFACES] Large objects, why not use the filesystem? |
Date: | 1999-02-01 13:46:03 |
Message-ID: | 002901be4de9$389a2f20$8d0835d1@bconnected.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
----- Original Message -----
From: Herouth Maoz <herouth(at)oumail(dot)openu(dot)ac(dot)il>
To: Gregory W Burnham <gburnham(at)sfu(dot)ca>
Cc: <pgsql-interfaces(at)postgreSQL(dot)org>
Sent: Monday, February 01, 1999 5:47 AM
Subject: Re: [INTERFACES] Large objects, why not use the filesystem?
>At 15:28 +0200 on 01/02/1999, Gregory W Burnham wrote:
>
>
>> Right, but I'm storing html and gif in my blobs and just
>> writing them out to stdout. Why shouldn't I just store
>> the file names and put the files right on the server?
>
>No reason at all. If it works for your application, then Buy Nike... oops,
>I meant "Just Do It". There are pros and cons for Blobs. If the pros don't
>hold for you, don't use Blobs.
Right, obviously. I'd just always assumed that lo_s were more
efficient. Now one of my beliefs is shot and I'm crushed. But
don't worry, I'll be ok.
>> To quote a friend of mine, "Efficiency is an issue only when
>> inefficiency is a problem." But still, you want to be as
>> efficient as possible, right? In retrospec, it would have
>> been more efficient to store all four digits of the year, right?
>
>Actually, it would simply have postponed the problem to a later date...
We should be using 5 digits, right?
Gregory W Burnham
Software Engineer
Excite Labs
Faculty Of Education
Simon Fraser University
Vancouver, BC, V5A 1S6
604 291 3615 (ph)
604 291 5679 (fx)
From | Date | Subject | |
---|---|---|---|
Next Message | Herouth Maoz | 1999-02-01 13:47:30 | Re: [INTERFACES] Large objects, why not use the filesystem? |
Previous Message | Peter T Mount | 1999-02-01 13:46:01 | Re: ResultSet.getDate |