This file is indexed.

/usr/share/doc/odbc-postgresql/docs/howto-accesslo.html is in odbc-postgresql 1:09.00.0310-2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
    <title>psqlODBC HOWTO - Access Large Objects</title>
  </HEAD>

  <body bgcolor="#ffffff" text="#000000" link="#ff0000" vlink="#a00000" alink="#0000ff">
  
<h1>psqlODBC HOWTO - Access Large Objects</h1>

<p>

<i>
Author: Unknown<br>
Release Date: Unknown<br>
Description: Using large objects in Microsoft Access (notes from the original psqlODBC docs)
</i>
<br><br>

<h2>Using Large Objects for handling LongVarBinary (OLE Objects in Access)</h2>

<p>Large objects are mapped to LONGVARBINARY in the driver to allow storing things like
OLE objects in Microsoft Access.  Multiple SQLPutData and SQLGetData calls are usually
used to send and retrieve these objects.  The driver creates a new large object and simply
inserts its 'identifier' into the respective table.  However, since PostgreSQL uses an 'Oid'
to identify a Large Object, it is necessary to create a new PostgreSQL type to be able
to discriminate between an ordinary Oid and a Large Object Oid.  Until this new type
becomes an official part of PostgreSQL, it must be added into the desired database and
looked up for each connection.  The type used in the driver is simply called "lo" and
here is the command used to create it:</p>

<blockquote>
<pre>
create type lo (
    internallength=4,
    externallength=10,
    input=int4in,
    output=int4out,
    default='',
    passedbyvalue
);
</pre>
</blockquote>

<p>Once this is done, simply use the new 'lo' type to define columns in that database.  Note
that this must be done for each database you want to use large objects in with the driver.
When the driver sees an 'lo' type, it will handle it as LONGVARBINARY.</p>

<p>Another important note is that this new type is lacking in functionality.  It will not
cleanup after itself on updates and deletes, thus leaving orphans around and using up
extra disk space.  And currently, PostgreSQL does not support the vacuuming of large
objects.  Hopefully in the future, a real large object data type will be available.</p>

<p>But for now, it sure is fun to stick a Word document, Visio document, or avi of a dancing
baby into a database column, even if you will fill up your server's hard disk after a while!</p>

</body>
</html>