Re: Picture with Postgres and Delphi
От | Network Administrator |
---|---|
Тема | Re: Picture with Postgres and Delphi |
Дата | |
Msg-id | 1063325138.3f610dd2e43d3@webmail.vcsn.com обсуждение исходный текст |
Ответ на | Re: Picture with Postgres and Delphi (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Picture with Postgres and Delphi
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | 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 по дате отправления: