Annamalai Gurusami <annamalai.gurusami@xxxxxxxxx> writes: > On 2 April 2011 11:17, John R Pierce <pierce@xxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
