From: | Dustin Sallings <dustin(at)spy(dot)net> |
---|---|
To: | jini us <jiniusuk(at)yahoo(dot)co(dot)uk> |
Cc: | pgsql-general(at)postgresql(dot)org, Christopher Browne <cbbrowne(at)acm(dot)org> |
Subject: | Re: embedded postgresql |
Date: | 2003-11-14 23:15:09 |
Message-ID: | 645B858F-16F8-11D8-9BF4-000393CFE6B8@spy.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Nov 14, 2003, at 14:13, jini us wrote:
> I would class your solution as a work around
> rather than a "natural solution".
It really seemed like the obvious way to do it (I'm sure I'm not the
only person who thought of that, but didn't post it).
> Anyway I am using MS windows and to implement
> postgres as embedded, using your approach, would
> probably become complicated.
> .It would probably introduce unwanted bugs in my
> software.
I believe it would be you introducing those bugs if you do not
initialize the DB correctly, regardless of the mechanism.
Now, how many bugs do you think it would create in postgres if the
entire interface model were changed from postmaster/postgres processes
to having multiple threads in a single application trying to issue
queries in the in-process DB. What happens to the DB when your app
segfaults? Are there any signal handlers postgres uses that you would
want to use in your app? Do you really need to redesign the way
postgres works just because you don't want to manage the resource as a
process rather than a different type of API?
--
Dustin Sallings
From | Date | Subject | |
---|---|---|---|
Next Message | Doug McNaught | 2003-11-14 23:18:46 | Re: GUIDs |
Previous Message | Dmitry Tkach | 2003-11-14 23:00:22 | What are these files about? |