Re: Scanning a large binary field

From: Sam Mason <sam(at)samason(dot)me(dot)uk>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Scanning a large binary field
Date: 2009-03-16 12:20:26
Message-ID: 20090316122026.GY32672@frubble.xen.chris-lamb.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, Mar 15, 2009 at 02:25:11PM -0700, John R Pierce wrote:
> Kynn Jones wrote:
> >That's a fair question. The program in question already gets from the
> >relational database most of the external data it needs. The only
> >exception to this is these large amorphous blobs, as you describe
> >them. My only reason for wanting to put the blobs in the DB as well
> >is to consolidate all the external data sources for the program.
>
> well, look at the LO (large object) facility of postgres. this is
> available to apps that call libpq directly, I have no idea if any of the
> generic 'portable' APIs would have any such hooks.

They are all exposed as normal SQL functions that can be used as needed;
I've just gone through the pain of getting VB to talk to them which
included writing base64 encoding and decoding routines as VB didn't seem
to be very reliable at handling non-ascii characters.

The C library interface is documented here:

http://www.postgresql.org/docs/current/static/lo-interfaces.html

and the SQL level variants are named similarly (sometimes without an
underscore in the name) and have identical semantics.

--
Sam http://samason.me.uk/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Janning Vygen 2009-03-16 13:15:59 large table starting sequence scan because of default_statistic_target
Previous Message Cédric Villemain 2009-03-16 08:39:30 Re: [Pkg-postgresql-public] Postgres major version support policy on Debian