| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: proposal: lob conversion functionality |
| Date: | 2013-10-21 19:54:17 |
| Message-ID: | 20131021195416.GB431885@tornado.leadboat.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Oct 21, 2013 at 08:10:24PM +0200, Pavel Stehule wrote:
> > On 10/20/2013 07:52 PM, Noah Misch wrote:
> >> Anything we do here effectively provides wrappers around the existing
> >> functions tailored toward the needs of libpq.
To clarify the above statement: the existing lo* SQL functions are designed to
fit the needs of the libpq APIs that call those SQL functions internally. The
additions we're discussing are SQL functions designed to fit the needs of
user-written SQL statements.
> I am for including to core - we have no buildin SQL functions that allows
> access simple and fast access on binary level. Next - these functions
> completes lo functionality.
>
> Other questions - should be these functions propagated to libpq?
No; I agree that the existing libpq large object API is adequate.
> and who will write patch? You or me?
If you're prepared to change the function names and add the subset-oriented
functions, I would appreciate that.
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2013-10-21 19:57:02 | Re: Turning recovery.conf into GUCs |
| Previous Message | Gavin Flower | 2013-10-21 19:52:16 | Re: Add min and max execute statement time in pg_stat_statement |