Tom Lane wrote:
> Adam Haberlach <haberlaa(at)ricochet(dot)net> writes:
> > I would like to know if there is a simple solution to this as well,
> > or if it will be addressed in the future.
> It'll probably get fixed someday, but the solution is not trivial;
> don't hold your breath. I'd guess that it might happen two or three
> releases from now, say six months to a year away. (This has been
> discussed many times before, so check the pgsql-hackers list archives
> if you want details about the technical issues.)
> In the meantime, your options for large text fields are (1) split them
> into multiple database records, or (2) store them in "large objects".
> Both are pretty ugly :-(
> regards, tom lane
Of course you can store them in your file system as separate files and store
their filename as a column in a table. This approach eats up inodes pretty
quickly, though, so its not the best solution. I recently thought of another
option; instead of storing them as separate files do the following:
1) Write out a file with a unique name (one that is unique to the table in
which you store the name).
2) Now run "ar" and insert the file into an archive named after the column
in the database:
ar r archive filename
3) Now delete the file from the file system.
When you want to retrieve this file from the archive type:
ar p archive filename
When you want to update just repeat the same process as above.
Normally, "ar" is used to create libraries of object files; the thing is that
is it's "normal" use but it will create an _updatable_ archive of any type of
file (text files being the ones in question now).
In response to
pgsql-interfaces by date
|Next:||From: Peter Mount||Date: 1999-03-30 08:55:17|
|Subject: Contacting me|
|Previous:||From: Wojciech Kromer||Date: 1999-03-29 16:19:01|
|Subject: [INTERFACES] type error inserting large obj, Win32 ODBC |