Re: Picture with Postgres and Delphi

From: Network Administrator <netadmin(at)vcsn(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jonathan Bartlett <johnnyb(at)eskimo(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Picture with Postgres and Delphi
Date: 2003-09-12 00:05:38
Message-ID: 1063325138.3f610dd2e43d3@webmail.vcsn.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Quoting Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Network Administrator <netadmin(at)vcsn(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Richard Welty 2003-09-12 00:07:56 library version problem, 7.3.2, php, redhat linux
Previous Message Joseph Shraibman 2003-09-12 00:04:16 selecting random rows