.
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
31 matches
Mail list logo
