Re: [ADMIN] Problem with lo_export() and lo_import() from remote machine. - Mailing list pgsql-general

From Marco Bizzarri
Subject Re: [ADMIN] Problem with lo_export() and lo_import() from remote machine.
Date
Msg-id 3f0d61c40609110307k62ecfc58w93b4e82fb8d8019@mail.gmail.com
Whole thread Raw
In response to Re: [ADMIN] Problem with lo_export() and lo_import() from remote machine.  ("Purusothaman A" <purusothaman.a@gmail.com>)
List pgsql-general
Actually, you can use direclty the lo_create, lo_open, lo_read and
lo_write directly into your SQL code, instead of having to write a
wrapper function. It is not simple, but it can be done.

I don't have a general example: we have done this in a couple of our
projects, one being public availabe (www.paflow.it): look in the
Documents.py source, and look for the lo_xxx queries.

This is indipendent from the fact that client and server are running
on the same server.

Regards
Marco


On 9/11/06, Purusothaman A <purusothaman.a@gmail.com> wrote:
> Thanks Martijn van Oosterhout,
>
> So, I have to write my own wrapper function upon the functions below.
>    1. Oid lo_import(PGconn *conn, const char *filename);
>    2. int lo_export(PGconn *conn, Oid lobjId, const char *filename);
>
> Am I right?
>
> :)
> Purusothaman A
>
>
> On 9/11/06, Martijn van Oosterhout <kleptog@svana.org> wrote:
> >
> Short answer, you can't. The database server can obviously only access
> things on the database server. Since SQL is also executed on the
> server, no SQL statements can access stuff on the client computer.
>
> If you want to load a file on the client side to the server, you need
> to open the file and copy it over using the lo_ functions. There no way
> (IIRC) to access the contents of large objects from just SQL.
>
> Hope this helps,
>
> On Mon, Sep 11, 2006 at 02:45:10PM +0530, Purusothaman A wrote:
> > Hi Martijn van Oosterhout,
> >
> > Thanks for your valuable reply.
> >
> > Yes I misunderstood the documentation.
> >
> > Then, I searched PostgreSQL documentation for equivalent client-side
> > functions.
> > But I found only C programming APIs instead of SQL functions.
> >
> > I want functions which is usable in SQL statements.
> >
> > Can you give example or equivalent client side function syntax?
> >
> > Thanks in advance.
> >
> > :)
> > Purusothaman A
> >
> >
> >
> >
> > On 9/9/06, Martijn van Oosterhout <kleptog@svana.org> wrote:
> > >
> > >On Sat, Sep 09, 2006 at 05:19:26PM +0530, Purusothaman A wrote:
> > >> I usually log in to postgresql server with admin username.
> > >>
> > >> But whatever its, according to documentation, if client machine's user
> > >has
> > >> write access
> > >> permission, this query should successfully be executed.
> > >
> > >Read carefully, you are using the server-side functions, therefore:
> > >
> > >"These two functions read and write files in the server's file system,
> > >using the permissions of the database's owning user."
> > >
> > >What your client user is is irrelevent. Perhaps you actually want to
> > >use the client-side functions?
> > >
> > >Have a nice day,
> > >--
> > >Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> > >> From each according to his ability. To each according to his ability to
> > >litigate.
> > >
> > >
> > >-----BEGIN PGP SIGNATURE-----
> > >Version: GnuPG v1.4.1 (GNU/Linux)
> > >
> >
> >iD8DBQFFAq41IB7bNG8LQkwRAsptAKCDSWuRI5T+JMqpWEQt7r69kJE6CwCfVTOO
> > >mOqGDNQBTZZDs4WVf6NM+wQ=
> > >=kT4s
> > >-----END PGP SIGNATURE-----
> > >
> > >
> > >
>
> --
> Martijn van Oosterhout   <kleptog@svana.org >   http://svana.org/kleptog/
> > From each according to his ability. To each according to his ability to
> litigate.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFFBS6LIB7bNG8LQkwRAvI6AJ9OW7cxZiJR0QsEsSOwkYHKkYDZ6gCbBrDA
> GVPAoBeOhE+2toFa2zNbN3M=
> =9W8I
> -----END PGP SIGNATURE-----
>
>
>
>


--
Marco Bizzarri
http://notenotturne.blogspot.com/

pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Plan for outer joins
Next
From: "Purusothaman A"
Date:
Subject: Re: [ADMIN] Problem with lo_export() and lo_import() from remote machine.