Tom Lane <tgl@sss.pgh.pa.us> Friday 03 of June 2011 16:44:13
> Alvaro Herrera <alvherre@commandprompt.com> 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 longer-than-30 bit length words for
> > varlena, I'm not sure we have room for that.)
>
> You wouldn't want to push such values around as whole values anyway.
> Possibly what would work here is a variant form of TOAST pointer for
> which we'd simply throw error if you tried to fetch the entire value
> at once.
>
> regards, tom lane
I mentoined about JDBC call.
1.
b = conn.createBlob();
ps = conn.preparesStatement("INSRT INTO t blob = ?");
ps.setBlob(1, b);
ps.executeQuery();
2.
Statements could be as well too
"SELECT blob_index_of(?, ?)";
where 1st ? is blob, 2nd one is some text/sequence
This call must be supported to make BLOB as far as possible simillar to other
types, this actually disallow to put LOB in TOAST as there is no relation (2.)
or relation is not known (1.) during reading LOB - in any case you can't skip
bytes from protocol stream, so possible solutions are:
1. Create temporaly LOB in file or memory depending of it size.
2. Use existing Large Object interface.
3. Client will not send LOB, just it's faked ID and during call Server will
ask client to serialize this LOB, by faked id.
4. Any other propositions?
I vote for 2.
For pg_type/class changes I think about removing haslobs, and put this as
attstorage or somewhere else for example ('l' may stand for lobs or -3
length), but currently TOAST composites doesn't support recursion, and those
types are toasted as whole. I may add recursion for those types, and support
special maintain for LOBs. In any case handling this will be better in
toasting code, not in nodeModifyTable.
Any ideas about this?
Reagrds,
Radek