Re: serverless postgresql

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
>
>