This is just what I recommended (I think) in my earlier post. This would be
FANTASTIC. Then I could scrap sqlite and any sqlite custom code that I end
up having to write (there is a little). Plus I could have the reliability
of a multi-process postgres "embedded".
Now if they just finish the Win32 port sometime soon...
----- Original Message -----
From: "Jonathan Bartlett" <johnnyb@eskimo.com>
To: "Rick Gigger" <rick@alpinenetworking.com>
Cc: "Jeff Bowden" <jlb@houseofdistraction.com>; "Tom Lane"
<tgl@sss.pgh.pa.us>; <pgsql-general@postgresql.org>
Sent: Wednesday, January 14, 2004 2:07 PM
Subject: Re: [GENERAL] serverless postgresql
> > Anyway since postgres uses WAL files to verify the integrity of the
database
> > couldn't it more or less make the same guarantee's in an embedded
version?
> > As long as the app uses the db libs unmodified and doesn't mess with the
> > files it creates how does simply making it embedded increase the change
of
> > db errors resulting in database corruption?
>
> I have a different idea. I've been thinking about coding it, but haven't
> had the time. This could be done with no changes to Postgres itself.
>
> Basically, you would have a library which exported functions such as
>
> pg_instance *pg_start(char *directory);
> pg_get_connection(pg_instance *);
> pg_stop(pg_instance *);
> pg_initdb(char *directory)
>
> pg_start would do the following:
> 1) check "directory" for an instance of the UNIX socket.
> if it is there, make a Postgres connection
> if it is not there, start the Postmaster server with "-k directory
> -D directory/data" and then make a Postgres connection
> 2) Create a struct to contain the directory and any other data item we
> need to connect to the database
> 3) Return this structure
>
> pg_get_connection would just be a wrapper for pq_connect()
>
> pg_stop would kill the database.
>
> pg_initdb would simply run initdb
>
> Does anyone see a reason why this wouldn't work?
>
> Jon
>
>
