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
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 |