Centuries ago, Nostradamus foresaw when scott.marlowe@ihs.com ("scott.marlowe") would write:
> Postgresql is really not suited to embedded applications.
Counterpoint: People tend to think about "embedded" in one of two
ways:
1. Applications using PICs and memory devices with _really_ limited
lifetimes, where the RIGHT answer is probably something like
Sleepycat DB, or perhaps, for persistent data, DJB's "constant
database" (cdb).
Relational systems Need Not Apply; the implementation language
is liable to be one of [8051 assembler|C|Forth], and even SQLite
is likely to be way too big.
This sort of gentle programmer should order Leo Brodie's book
_Thinking Forth_, and see how Forth BLOCKs may be used as a
virtual memory 'database.'
2. They have megabytes of memory, lots of room for the GUI fluff
that they're doing, and want a database that isn't really
'getting in their way.'
In this sort of case, MySQL and SQLite and Firebird propose the
answer that you can "link them in" to your application, and
thereby have data storage embedded in the application.
PostgreSQL is designed in a manner that actively discourages
that particular approach; it wants there to be a separate
"postmaster" process. But I am unconvinced that this means you
_can't_ design the application in a manner where PostgreSQL can
hide alongside, and still "stay mostly out of the way."
Indeed, the fact that PostgreSQL runs as a separate process
seems to me to be an excellent way of "staying out of the way."
In contrast, the need, with "embedded in the same process"
systems, to have things like event loops and the need to start
up the database within your application is anything but "staying
out of the way."
But we don't really know where the O.P. is biasing in preference,
whether there's no memory and no disk, or whether it's just the matter
of "veiling" the presence of the DBMS.
--
output = ("cbbrowne" "@" "cbbrowne.com")
http://cbbrowne.com/info/x.html
Life's a duck, and then you sigh.
