Network Administrator <netadmin@vcsn.com> writes:
> I thought "bytea" was PG's version of BLOBs.
Not really (or not yet). Usually when people talk about blobs, they are
thinking of a feature that lets them store a large amount of data in one
table entry, and that provides the ability to read and write that data
sequentially (ie, not all at once, but in conveniently-sized chunks).
Commonly this means that you open a "handle" or "cursor" referring to
one particular blob and then read or write it through that handle.
If we had such I/O handles for bytea (and maybe text too), then we'd
have full-fledged blobs. Right now, bytea can store a large amount of
data, but you have to supply it all in one chunk, and you can only read
out subsets by means of SUBSTR, which isn't especially convenient or
efficient.
What we do have are Postgres-style large objects, which are not quite
the same concept, mainly because they are objects that have existence
independently of any particular row that might reference them. This is
a good thing for a few applications, but most people just find that it
creates a garbage-collection problem ... they'd rather a blob went away
when they deleted the table row that uses it. PG-style large objects
also lack any access permission checking; anyone can read or write any
LO in the database.
Some of the people at Red Hat are hot to create handles/cursors for
bytea and friends, so maybe it will happen for 7.5. I'd be inclined
to think about obsoleting Postgres-style large objects someday, if we
had the more common kind of blob support.
regards, tom lane
