Re: BLOB support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Radosław Smogura <rsmogura(at)softperience(dot)eu>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BLOB support
Date: 2011-06-06 14:13:26
Message-ID: 26289.1307369606@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?UTF-8?Q?Rados=C5=82aw_Smogura?= <rsmogura(at)softperience(dot)eu> 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 someonetubevideos values (?)")
> where 1st parameter is myWeddingDvd,

Yes, if you insist upon designing the API like that, then you come to
the conclusion that you need global LOB identifiers.

However, there are many ways to design this that don't work that way.
One idea to think about is

insert into someonetubevideos values('')
returning open_for_write(videocolumn)

which gives you back some kind of writable stream ID (this is a
transient, within-session ID, not global) for the target field in the
row you just inserted.

BTW, as was noted upthread by Dimitri, this whole subject has been
discussed before on pgsql-hackers. You really ought to go re-read the
previous threads.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-06-06 14:49:25 Re: reducing the overhead of frequent table locks - now, with WIP patch
Previous Message Robert Haas 2011-06-06 13:58:50 Re: WIP: AuthenticationMD5 protocol documentation clarification