Re: [INTERFACES] Large objects, why not use the filesystem?
От | Tom Lane |
---|---|
Тема | Re: [INTERFACES] Large objects, why not use the filesystem? |
Дата | |
Msg-id | 8275.917822495@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Large objects, why not use the filesystem? (Matthew Hagerty <matthew@wolfepub.com>) |
Список | pgsql-interfaces |
Matthew Hagerty <matthew@wolfepub.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
В списке pgsql-interfaces по дате отправления: