.
Regards,
Radek
-Original Message-
From: Tom Lane
Sent: 6 czerwca 2011 17:41
To: Radoslaw Smogura
Cc: Alvaro Herrera; Pavel Stehule; Dimitri Fontaine; Robert Haas; Peter
Eisentraut; PG Hackers
Subject: Re: [HACKERS] BLOB support
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> Introduc
On 06.06.2011 17:13, Tom Lane wrote:
=?UTF-8?Q?Rados=C5=82aw_Smogura?= writes:
I think more about this with contrast to sent references, but I still
have in my mind construct
Blob myWeddingDvd = conn.createBlob(myWeddingStream, size); //A bit
outdated we have BlueRay
conn.prepareState
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> Introducing streaming for TOAST is little useless, sorry just for cite from
> my, mentoined document:
> (This is generally about on demand stream of TOASTed value, in
> context of LOBs is acceptable, as long not transactional aware LOBs are
> accepta
Tom Lane Monday 06 of June 2011 16:13:26
> =?UTF-8?Q?Rados=C5=82aw_Smogura?= writes:
> > I think more about this with contrast to sent references, but I still
> > have in my mind construct
> > Blob myWeddingDvd = conn.createBlob(myWeddingStream, size); //A bit
> > outdated we have BlueRay
> >
=?UTF-8?Q?Rados=C5=82aw_Smogura?= writes:
> I think more about this with contrast to sent references, but I still
> have in my mind construct
> Blob myWeddingDvd = conn.createBlob(myWeddingStream, size); //A bit
> outdated we have BlueRay
> conn.prepareStatemnt("INSERT INTO someonetubevideo
2011/6/6 Radosław Smogura :
> On Sun, 05 Jun 2011 22:16:41 +0200, Dimitri Fontaine wrote:
>>
>> Tom Lane writes:
>>>
>>> Yes. I think the appropriate problem statement is "provide streaming
>>> access to large field values, as an alternative to just fetching/storing
>>> the entire value at once".
On Sun, 05 Jun 2011 22:16:41 +0200, Dimitri Fontaine wrote:
Tom Lane writes:
Yes. I think the appropriate problem statement is "provide
streaming
access to large field values, as an alternative to just
fetching/storing
the entire value at once". I see no good reason to import the
entire
mes
Tom Lane writes:
> Yes. I think the appropriate problem statement is "provide streaming
> access to large field values, as an alternative to just fetching/storing
> the entire value at once". I see no good reason to import the entire
> messy notion of LOBS/CLOBS. (The fact that other databases
Tom Lane Friday 03 of June 2011 16:44:13
> Alvaro Herrera writes:
> > Excerpts from RadosÅaw Smogura's message of jue jun 02 15:26:29 -0400
2011:
> >> So do I understand good should We think about create bettered TOAST to
> >> support larger values then 30-bit length? I like this much more,
> >
Tom Lane Friday 03 of June 2011 18:08:56
> Robert Haas writes:
> > On Thu, Jun 2, 2011 at 12:53 PM, RadosÅaw Smogura
> >
> > wrote:
> >> 1. No tracking of unused LO (you store just id of such object). You may
> >> leak LO after row remove/update. User may write triggers for this, but
> >> it i
Tom Lane Friday 03 of June 2011 16:44:13
> Alvaro Herrera writes:
> > Excerpts from RadosÅaw Smogura's message of jue jun 02 15:26:29 -0400
2011:
> >> So do I understand good should We think about create bettered TOAST to
> >> support larger values then 30-bit length? I like this much more,
> >
Robert Haas writes:
> On Thu, Jun 2, 2011 at 12:53 PM, RadosÅaw Smogura
> wrote:
>> 1. No tracking of unused LO (you store just id of such object). You may leak
>> LO after row remove/update. User may write triggers for this, but it is not
>> argument - BLOB type is popular, and it's simplicity
On Thu, Jun 2, 2011 at 12:53 PM, Radosław Smogura
wrote:
> 1. No tracking of unused LO (you store just id of such object). You may leak
> LO after row remove/update. User may write triggers for this, but it is not
> argument - BLOB type is popular, and it's simplicity of use is quite
> important.
Alvaro Herrera writes:
> Excerpts from RadosÅaw Smogura's message of jue jun 02 15:26:29 -0400 2011:
>> So do I understand good should We think about create bettered TOAST to
>> support
>> larger values then 30-bit length? I like this much more,
> Good :-)
> (BTW while it'd be good to have lo
Excerpts from Radosław Smogura's message of jue jun 02 15:26:29 -0400 2011:
> So do I understand good should We think about create bettered TOAST to
> support
> larger values then 30-bit length? I like this much more,
Good :-)
(BTW while it'd be good to have longer-than-30 bit length words for
On Thu, Jun 02, 2011 at 01:43:16PM -0400, Tom Lane wrote:
> =?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> > Tom Lane Thursday 02 of June 2011 16:42:42
> >> Yes. I think the appropriate problem statement is "provide streaming
> >> access to large field values, as an alternative to just fetching/sto
Dne 2.6.2011 15:18, k...@rice.edu napsal(a):
> On Thu, Jun 02, 2011 at 02:58:52PM +0200, Pavel Stehule wrote:
>> 2011/6/2 Peter Eisentraut :
>>> Superficially, this looks like a reimplementation of TOAST. What
>>> functionality exactly do you envision that the BLOB and CLOB types would
>>> need to
Dne 2.6.2011 15:49, Pavel Stehule napsal(a):
> 2011/6/2 Pavel Golub :
>> Hello, Pavel.
>>
>> You wrote:
>>
>> PS> 2011/6/2 Peter Eisentraut :
On ons, 2011-06-01 at 22:00 +0200, Radosław Smogura wrote:
> I partialy implemented following missing LOBs types. Requirement for this
> was
>>
Tom Lane Thursday 02 of June 2011 19:43:16
> =?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> > Tom Lane Thursday 02 of June 2011 16:42:42
> >
> >> Yes. I think the appropriate problem statement is "provide streaming
> >> access to large field values, as an alternative to just fetching/storing
> >>
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> Tom Lane Thursday 02 of June 2011 16:42:42
>> Yes. I think the appropriate problem statement is "provide streaming
>> access to large field values, as an alternative to just fetching/storing
>> the entire value at once". I see no good reason to import
Tom Lane Thursday 02 of June 2011 16:42:42
> Robert Haas writes:
> > But these problems can be fixed without inventing a completely new
> > system, I think. Or at least we should try. I can see the point of a
> > data type that is really a pointer to a LOB, and the LOB gets deleted
> > when the
2011/6/2 Tom Lane :
> Robert Haas writes:
>> But these problems can be fixed without inventing a completely new
>> system, I think. Or at least we should try. I can see the point of a
>> data type that is really a pointer to a LOB, and the LOB gets deleted
>> when the pointer is removed, but I d
Robert Haas writes:
> But these problems can be fixed without inventing a completely new
> system, I think. Or at least we should try. I can see the point of a
> data type that is really a pointer to a LOB, and the LOB gets deleted
> when the pointer is removed, but I don't think that should req
On Thu, Jun 2, 2011 at 9:29 AM, Radosław Smogura
wrote:
>> What functionality exactly do you envision that the BLOB and CLOB types
>> would
>> need to have that would warrant treating them different from, say, bytea
>> and text?
>
> Actually I thought about less sophisticated support of LOBs, supp
2011/6/2 Pavel Golub :
> Hello, Pavel.
>
> You wrote:
>
> PS> 2011/6/2 Peter Eisentraut :
>>> On ons, 2011-06-01 at 22:00 +0200, Radosław Smogura wrote:
I partialy implemented following missing LOBs types. Requirement for this
was
to give ability to create (B/C)LOB columns and add c
On Thu, 02 Jun 2011 15:39:39 +0300, Peter Eisentraut wrote:
On ons, 2011-06-01 at 22:00 +0200, Radosław Smogura wrote:
I partialy implemented following missing LOBs types. Requirement for
this was
to give ability to create (B/C)LOB columns and add casting
functionality e.g.
SET my_clob = 'My l
Hello, Pavel.
You wrote:
PS> 2011/6/2 Peter Eisentraut :
>> On ons, 2011-06-01 at 22:00 +0200, Radosław Smogura wrote:
>>> I partialy implemented following missing LOBs types. Requirement for this
>>> was
>>> to give ability to create (B/C)LOB columns and add casting functionality
>>> e.g.
>>>
On Thu, Jun 02, 2011 at 02:58:52PM +0200, Pavel Stehule wrote:
> 2011/6/2 Peter Eisentraut :
> > On ons, 2011-06-01 at 22:00 +0200, Radosław Smogura wrote:
> >> I partialy implemented following missing LOBs types. Requirement for this
> >> was
> >> to give ability to create (B/C)LOB columns and ad
2011/6/2 Peter Eisentraut :
> On ons, 2011-06-01 at 22:00 +0200, Radosław Smogura wrote:
>> I partialy implemented following missing LOBs types. Requirement for this was
>> to give ability to create (B/C)LOB columns and add casting functionality e.g.
>> SET my_clob = 'My long text'.
>>
>> Idea is a
On ons, 2011-06-01 at 22:00 +0200, Radosław Smogura wrote:
> I partialy implemented following missing LOBs types. Requirement for this was
> to give ability to create (B/C)LOB columns and add casting functionality e.g.
> SET my_clob = 'My long text'.
>
> Idea is as follow:
> 0. Blob is two state
Hello,
I partialy implemented following missing LOBs types. Requirement for this was
to give ability to create (B/C)LOB columns and add casting functionality e.g.
SET my_clob = 'My long text'.
Idea is as follow:
0. Blob is two state object: 1st in memory contains just bytea, serialized
contain
Christopher Kings-Lynne writes:
> Is there some reason why we didn't call text 'clob' and bytea 'blob'?
At the time our types were created there was no standard defining the
other types.
> or at least add aliases?
Mapping clob to text might be OK, but blob and bytea have totally
different inpu
> I would like to inquire how is the BLOB support in
> PostgreSQL is doing
> > now? Had there been some improvements? Can I have the blob
> support like in
>
> I'm unsure about blob (didn't know we had a blob type), but bytea works
> perfectly fine for that.
Is there some reason why we didn't
On Wed, 2002-09-18 at 18:32, Manuel Cabido wrote:
> Hi PostgreSQL Folks,
>
> I would like to inquire how is the BLOB support in PostgreSQL is doing
> now? Had there been some improvements? Can I have the blob support like in
I'm unsure about blob (didn't know we had a blob type), but bytea
Hi PostgreSQL Folks,
I would like to inquire how is the BLOB support in PostgreSQL is doing
now? Had there been some improvements? Can I have the blob support like in
this manner?
create table myblob (
blobid serial not null primary key,
namevarchar(50),
I'm interested by TOAST, and I have asked several questions on the subject...
I haven't tested them yet...
First I thought that the type bytea allows storing of binary data, a BSOB
(Binary Small OBject).
Secondly that by using a binary cursor you have access to the raw data as it
is stored in the
Olivier PRENANT wrote:
> Hi Bruce,
>
> Any idea when it's due for??
> I've been thining about writing a user function; But I'll get stuck with
> permission as a user function is running under the "postgres" or whatever
> user instead of the calling user.
>
> Also, what kind of binary interface are
Bruce Momjian wrote:
> > Hi Bruce,
> >
> > Any idea when it's due for??
>
> When? Probably not until 7.2, which is a pain.
We cannot use TOAST as is for BLOB/CLOB storage with a binary
IO interface over fastpath.
The reason is that you cannot force a column to be moved off
anyw
Bruce Momjian wrote:
>
> I would LOVE to see it in a minor 7.1.X release.
It's *feature* with alot necessary coding in core
functionality below heap access methods. Not a good candidate
for a bugfix release.
Jan
>
>
> > Bruce,
> >
> > Thanks for replying (I know you're
Bruce,
Thanks for replying (I know you're a busy man :)
Any chance to have it backported to 7.1 or maybe in contrib???
This is a feature w all gonna lack (with GiST...)
Regards,
On Mon, 29 Jan 2001, Bruce Momjian wrote:
> > Hi Bruce,
> >
> > Any idea when it's due for??
> > I've been thining
I would LOVE to see it in a minor 7.1.X release.
> Bruce,
>
> Thanks for replying (I know you're a busy man :)
>
> Any chance to have it backported to 7.1 or maybe in contrib???
>
> This is a feature w all gonna lack (with GiST...)
>
> Regards,
> On Mon, 29 Jan 2001, Bruce Momjian wrote:
>
> Hi Bruce,
>
> Any idea when it's due for??
When? Probably not until 7.2, which is a pain.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be y
> Hi Bruce,
>
> Any idea when it's due for??
> I've been thining about writing a user function; But I'll get stuck with
> permission as a user function is running under the "postgres" or whatever
> user instead of the calling user.
>
> Also, what kind of binary interface are you thinking of??
L
Hi Bruce,
Any idea when it's due for??
I've been thining about writing a user function; But I'll get stuck with
permission as a user function is running under the "postgres" or whatever
user instead of the calling user.
Also, what kind of binary interface are you thinking of??
Regards,
On Sun,
I trying to implement a custom
datatype and after I have read
the docs I understand that I should
use large objects is the data type
is to bigger than 8K.
I have one question about using
BLOBs in my intended work:
-is there a way to automate the
the creation of new object when
a new row is insert
45 matches
Mail list logo
