Clinging to sanity, [EMAIL PROTECTED] mumbled into her beard: > I would like to know if there are any discussions about > creating an embedded version on postgresql. My thoughts > go towards building/porting a sqlite equivalent of pg.
People periodically "drive by" and suggest that PostgreSQL would become fabulously better (or fabulously more popular) if it were rewritten to do an in-process embedding of it. There is little enthusiasm for the idea, as it would substantially reduce the robustness of the system. It also seems quite curious why in-process embedding should be so attractive; it _looks_ as though most of the people that are so excited about this idea have a pretty defective understanding of Unix, and have missed the point that spawning extra processes to do different kinds of work is a FEATURE. The people with that defective understanding generally go away unsatisfied. If you really and truly want an "embedded" database, then you really should look at Berkeley DB and SQLite. They may save you a bit of memory if you only have one application that can make use of a database. If you have a second application, or perhaps more than two, it's pretty likely that linking to libpq and talking to a full-fledged server will be a win. -- (format nil "[EMAIL PROTECTED]" "cbbrowne" "ntlug.org") http://www.ntlug.org/~cbbrowne/spreadsheets.html ... it's just that in C++ and the like, you don't trust _anybody_, and in CLOS you basically trust everybody. the practical result is that thieves and bums use C++ and nice people use CLOS. -- Erik Naggum ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
