Thread

1. Tom Lane

   Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> — 2000-09-06T05:42:02Z

   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."
   --
   
   

2. Re: Tom Lane

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-09-06T14:26:20Z

   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
   
   

3. Re: Tom Lane

   Tatsuo Ishii <t-ishii@sra.co.jp> — 2000-09-07T04:59:46Z

   > 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
   
   

4. Re: Tom Lane

   Jan Wieck <janwieck@yahoo.com> — 2000-09-07T09:50:13Z

   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 #