Re: Merged Model for libpq - Mailing list pgsql-general

On Sun, Apr 3, 2011 at 11:43 PM, Annamalai Gurusami
<annamalai.gurusami@gmail.com> wrote:
> On 2 April 2011 11:17, John R Pierce <pierce@hogranch.com> wrote:
>
>> what you describe is neither postgres nor SQL
>>
>> perhaps you should look at a storage engine like BerkeleyDB
>
> I hope that not everybody dismisses this mail thread because of the
> above response.  We are deriving our product from pgsql.  And since we
> are customizing pgsql to our proprietary telecom products, we are
> using things that are not designed for that purpose.  For example, we
> are using SPI to come up with an embedded client.  I was basically
> trying to find out if there are better alternatives.  Have the pgsql
> development team thought about embedded clients and is SPI the way to
> go?
>
> What we are trying to achieve is that a single application can work as
> an ordinary client or an embedded client.  For example, if we
> implement libpq using SPI interface then any libpq client can behave
> as an ordinary client (using current libpq library) or as an embedded
> client (by making use of libpq over SPI - which we are implementing).
>
> I have no clue as to why you have recommended BerkeleyDB in this
> context!  What I have described is pgsql and the applications all use
> SQL queries.  If somethings are not clear and requires further
> elaboration from me, kindly let me know.  Providing inputs to extend
> pgsql in a proper well-defined way will help us to contribute back the
> feature to pgsql (if my company decides so and if pgsql needs it.)
> Even if the feature is not contributed back, if the pgsql dev team
> finds it a useful feature, anybody can implement it.

I'm not sure you grasped the ramification of my message upthread.
There is a lot of use for libpq (or libpq-ish) api in the backend to
execute queries.  Unfortunately, that api can not wrap the SPI
interface as it exists today.  The SPI interface is for writing
backend functions, not application code.  Those functions *must* be
called from the application layer, and *must* terminate within a
reasonable amount of time (think seconds).  I think you are looking in
the wrong place -- if you want to embed a libpq api in the backend,
perhaps you might want to look at wrapping the backend in standalone
mode.  This has issues that will prevent general use in an
application, but it's a start, and should give you an idea of what you
are up against.

A more involved project would be to look at modifying the postgresql
internals so that you could usefully embed code and run it with
explicit transaction control.  This is a pretty big task and would
likely end up as a complete stored procedure implementation.  If done
though, you could run in a more or less clientless way.

PostgreSQL today can not usefully operate without participation from a
client (although that client can be quite thin if you want it to be).
Having 100% of your application in SPI layer is *not* going to work.

merlin