Re: 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(at)nimrod(dot)itg(dot)telstra(dot)com(dot)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(at)Yahoo(dot)com #