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