Re: Picture with Postgres and Delphi - Mailing list pgsql-general

From Network Administrator
Subject Re: Picture with Postgres and Delphi
Date
Msg-id 1063325138.3f610dd2e43d3@webmail.vcsn.com
Whole thread Raw
In response to Re: Picture with Postgres and Delphi  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Picture with Postgres and Delphi  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
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

pgsql-general by date:

Previous
From: Joseph Shraibman
Date:
Subject: selecting random rows
Next
From: Richard Welty
Date:
Subject: library version problem, 7.3.2, php, redhat linux