Quoting Tom Lane <tgl@sss.pgh.pa.us>:
> 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.
Ok, I see. Without the I/O facilites for bytea and text, you have to write a
"loader" in another language that access the filesystem. With BLOBs, the
facilites are there natively.
I would think in the case of binary files reading subsets would not
be necessary for serving images (say for ads spot on a web page). Isn't it more
efficient to use bytea of text type for large objects and let the the interface
layer handle the trottling to the data to/from the user?
> 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.
Ok. I couldn't use that because of the security issue you mention.
> 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
I understand the value of handles but aren't cursors used to break up the large
result sets from queries?
--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com
____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com