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/
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 |