Re: Merged Model for libpq

Annamalai Gurusami <annamalai(dot)gurusami(at)gmail(dot)com> writes:
> On 2 April 2011 11:17, John R Pierce <pierce(at)hogranch(dot)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?

I don't think you've entirely grasped the seriousness of that response.
The PG development team *has* thought about embedded scenarios, and
explicitly rejected them. There is no interest at all here in that line
of development, and we are unlikely to even consider patches that might
make it easier. We don't like the reliability implications of having
random client code in the same address space as the database code.
Moreover, the general trend of recent development has been towards
making the database more, not less, dependent on auxiliary processes
such as autovacuum and bgwriter. There's no way to manage that in an
embedded scenario ... at least not without resorting to threads, which
is another thing that we are unprepared to support.

So really you should be looking at some other DBMS if you want an
embedded implementation. It'd be nice if PG could be all things to all
people, but it can't; and this is one of the things it can't be.

regards, tom lane