Thread: Tom Lane
Tom, the following was said in the apache turbine project mailing list a while back regarding telling the difference between an ordinary oid column and an oid column that points to a large object. Can you confirm if this is true regarding the reference to change in v 7.1 ? -- "That's why they didn't want my patch which changed the SQL Type returned by the metadata from Integer to Varbinary, because it'll break anybody who uses it as an int (which is what it really is). But the problem is that there is no datatype called, "Image" or "varbinary," the only way you can use a large object field is by setting the column datatype to OID. It's ambiguous...I don't use that datatype for anything but large objects, so the patch works for me, but I understand why they don't want it in the main dist. of the driver. Tom Lane from the pgsql team told me that in v 7.1 there will be a way to identify the difference between a binary column and an oid column." --
Chris <chrisb@nimrod.itg.telstra.com.au> writes:
> Tom, the following was said in the apache turbine project mailing list a
> while back regarding telling the difference between an ordinary oid
> column and an oid column that points to a large object. Can you confirm
> if this is true regarding the reference to change in v 7.1 ?
> Tom Lane from the pgsql team told me that in v 7.1 there will be a way
> to identify the difference between a binary column and an oid column."
I don't recall saying any such thing, sorry (at least not as far as the
backend is concerned --- the particular issue you are quoting seemed to
be just an ODBC driver question).
There already is a solution of sorts in contrib/lo, if you care to use
it. I seem to recall speculating that it'd be a good idea to move that
into the mainstream, but nothing's been done about it.
I think we are mostly waiting to see how much usage of LOs remains after
people get comfortable with TOAST --- it may be that improving the LO
facilities beyond where they are will just be gilding a dead lily.
I do plan to check over and commit Denis Perchine's fix to store large
objects in a single table, instead of two files per LO (see patches list
for 6/27/00). That should solve our existing performance problems with
thousands of LOs, and since he already did the work it'd be silly not to
include it. Beyond that I'm in wait-and-see mode for more LO work.
regards, tom lane
> I think we are mostly waiting to see how much usage of LOs remains after > people get comfortable with TOAST --- it may be that improving the LO > facilities beyond where they are will just be gilding a dead lily. BTW, I'd really want to use BLOB/CLOB using TOAST. Anyone working on this part? -- Tatsuo Ishii
Tatsuo Ishii wrote: > > I think we are mostly waiting to see how much usage of LOs remains after > > people get comfortable with TOAST --- it may be that improving the LO > > facilities beyond where they are will just be gilding a dead lily. > > BTW, I'd really want to use BLOB/CLOB using TOAST. Anyone working on > this part? Thinking, making plans. But it's nothing to be written down quickly. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #