Re: [INTERFACES] Large objects, why not use the filesystem?

Matthew Hagerty <matthew(at)wolfepub(dot)com> writes:
> I always see posts of people trying to get their large binary and text
> objects into and out of the database somehow. I was wondering if there is
> some reason why just storing a filename in the table would be a bad thing?

Quite a number of people do exactly that.

It falls down though if you are trying to use Postgres in a multiple-
machine environment: the client applications don't necessarily have
access to the filesystem on the database machine. Even if they do,
there are security issues to think about: the access permissions for
the filesystem may be tighter or looser than your access permissions
for the database installation, and will certainly be *different*.

But if it gets the job done for you, go right ahead...

> Also, could someone explain varchar?

AFAIK varchar is just a variable-length string type with a specific
length limit set on a per-column basis. This is distinct from plain
char(n), which is a fixed-length string, and from text, which is a
variable-length string with no specific upper limit (short of the
implementation limit on total size of a tuple, that is).

There are probably a few small differences among the three types in
terms of the operations available, but this would be more in the nature
of an oversight (ie, someone forgot to write the operator routine) than
a fundamental property of the type.

varchar and text are essentially equivalent in terms of implementation
efficiency (space cost), too. I believe char(n) occupies the same
amount of space as a varchar or text that happens to be n characters
--- ie, there is a 4-byte overhead, even though it's not logically
necessary for char(n). I've been griping about that, but I doubt that
anything is likely to happen soon... too many other things on the
to-do list.

regards, tom lane