Re: embedded postgresql

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

In response to

Responses

Browse pgsql-general by date

  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?