Return-Path: mao
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA17563; Tue, 6 Jul 93 14:28:56 -0700
Message-Id: <9307062128.AA17563@postgres.Berkeley.EDU>
From: Mike Olson <mao@postgres.Berkeley.EDU>
Subject: Re: Confusion over large objects.
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: hamiltop@computer-science.manchester.ac.uk's message of 6 Jul 1993 5:47 PDT
Date: Tue, 06 Jul 1993 14:32:53 -0700
From: Mike Olson <mao@postgres.Berkeley.EDU>

M92 <hamiltop@computer-science.manchester.ac.uk> writes:

> If I use the libpq command p_creat to create a unix large object then a large
> object identifier is produced (LO*****, where ***** is an integer). However w
  +hen
> I use this command no matter what system path name I supply the large object
> file is created within postgres. Thus data written to the large object is wit
  +hinthe postgres file system and under the authority of the database administ
  +rator. My understanding of postgres large objects is that unix large objects
  + are part 
> of the unix file system and the data is not copied into postgres.

no, in either case the large object is copied into, owned by, and subject
to the control of the database system.  the difference is in how the
storage is managed -- as a unix file in the data/base/xxx directory,
or as a relation in the database.

> I'm also trying to use the LO* commands but the LO_read hangs-up when invoked
  +. I
> have a patch for the file inv_api.c but the systems administators are having
> difficulty in getting the postgres build file to recognise that an update has
  + 
> occurred. Any suggestions about this problem would be gratefully received.

you could always do

	bmake clean ; bmake all

in src/backend.  this'll do what you want.  the bmake files correctly
manage dependencies in my experience, but this will force recompilation
in case it's not working for you.

can you send me your inv_api.c patch?  i'd like to take a look at it.

					mike