delivering database stand-alone

Joost Kremers wrote:

hi all,

i am planning to build a database (a dictionary in fact) that i will
eventually want to distribute on a cd (or downloadable iso). what i would
like to know is if this is technically possible with postgresql. and how
exactly would it be done? would i have to make postgresql run off the cd,
or should it first be installed to the hard disk? (the latter would be
problematic on linux, given the many different distros and their different
package management systems...) how would i deal with systems that already
have a postgreql server or (more difficult perhaps) a different database
server running?

or should i not make use of postgresql (or any database server) at all for
the cd? after all, the data in the database is static, users will not have
to modify it, just look it up.

thanks for any comments and suggestions.

PostgreSQL will not run on read-only medium easily. If you vacuum full all
the tables, that will prevent table writes, but we write to pg_clog even
for select.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Martha Stewart called it a Good Thing whenjoostkremers@fastmail.fm (Joost Kremers)wrote:

i am planning to build a database (a dictionary in fact) that i will
eventually want to distribute on a cd (or downloadable iso). what i
would like to know is if this is technically possible with
postgresql. and how exactly would it be done? would i have to make
postgresql run off the cd, or should it first be installed to the
hard disk? (the latter would be problematic on linux, given the many
different distros and their different package management systems...)
how would i deal with systems that already have a postgreql server
or (more difficult perhaps) a different database server running?

or should i not make use of postgresql (or any database server) at
all for the cd? after all, the data in the database is static, users
will not have to modify it, just look it up.

This sounds like a candidate for Dan Bernstein's "CDB" (Constant
DataBase) library. It builds highly efficient "compiled" hash tables,
that are intended to be treated as "read-only." (In fact, they can't
readily be updated, once compiled.)

That presents three issues:

1. It's basically doing "hash table" access; no ordering; no
approximate matches.

2. No ability to submit SQL queries.

3. Discussions of DJB's licensing arrangements tends to cause brain
haemorraging, anger, and other ills. The Debian folk have
created an alternative version that I believe is in the
public domain (e.g. - not GPL; not LGPL; possibly "freer than
the BSD License").

In contrast, read-only access to PostgreSQL databases is, while
occasionally discussed, not currently attainable. (Not, at least, in
a "burn the DB on CD" form.)
--
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://www.ntlug.org/~cbbrowne/sap.html
"A crafty and lecherous old hypocrite whose very statue seems to gloat
on the wenches as they walk the States House Yard."
-- William Cobbett on Benjamin Franklin

On Mon, 2003-09-01 at 05:24, Joost Kremers wrote:

hi all,

i am planning to build a database (a dictionary in fact) that i will
eventually want to distribute on a cd (or downloadable iso). what i would
like to know is if this is technically possible with postgresql. and how
exactly would it be done? would i have to make postgresql run off the cd,
or should it first be installed to the hard disk? (the latter would be
problematic on linux, given the many different distros and their different
package management systems...) how would i deal with systems that already
have a postgreql server or (more difficult perhaps) a different database
server running?

or should i not make use of postgresql (or any database server) at all for
the cd? after all, the data in the database is static, users will not have
to modify it, just look it up.

I think I'd go with ISAM files. Simpler to relocate to any direc-
tory tree.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l.johnson@cox.net
Jefferson, LA USA

YODA: Code! Yes. A programmer's strength flows from code
maintainability. But beware of Perl. Terse syntax... more
than one way to do it...default variables. The dark side of code
maintainability are they. Easily they flow, quick to join you
when code you write. If once you start down the dark path,
forever will it dominate your destiny, consume you it will.

You should check out Firebird (firebirdsql.sourceforge.net). I believe
your can set databases to be read-only and when embedding, Firebird is
a single DLL.

Jacob

On Mon, 01 Sep 2003 15:42:32 -0400, Christopher Browne
<cbbrowne@acm.org> wrote:

-----Original Message-----
From: Christopher Browne [mailto:cbbrowne@acm.org]
Sent: Monday, September 01, 2003 12:43 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] delivering database stand-alone

Martha Stewart called it a Good Thing
whenjoostkremers@fastmail.fm (Joost Kremers)wrote:

i am planning to build a database (a dictionary in fact)

that i will

eventually want to distribute on a cd (or downloadable iso). what i
would like to know is if this is technically possible with

postgresql.

and how exactly would it be done? would i have to make

postgresql run

off the cd, or should it first be installed to the hard disk? (the
latter would be problematic on linux, given the many

different distros

and their different package management systems...) how would i deal
with systems that already have a postgreql server or (more

difficult

perhaps) a different database server running?

or should i not make use of postgresql (or any database

server) at all

for the cd? after all, the data in the database is static,

users will

not have to modify it, just look it up.

This sounds like a candidate for Dan Bernstein's "CDB" (Constant
DataBase) library. It builds highly efficient "compiled"
hash tables, that are intended to be treated as "read-only."
(In fact, they can't readily be updated, once compiled.)

That presents three issues:

1. It's basically doing "hash table" access; no ordering; no
approximate matches.

2. No ability to submit SQL queries.

3. Discussions of DJB's licensing arrangements tends to cause brain
haemorraging, anger, and other ills. The Debian folk have
created an alternative version that I believe is in the
public domain (e.g. - not GPL; not LGPL; possibly "freer than
the BSD License").

In contrast, read-only access to PostgreSQL databases is,
while occasionally discussed, not currently attainable.
(Not, at least, in a "burn the DB on CD" form.)

Something else to consider:
http://www.garret.ru/~knizhnik/databases.html

All freely available and open source. They all use OO paradigm, and so
will be uncomfortable for those who are not used to it.

DCorbit@connx.com ("Dann Corbit") wrote:

Something else to consider:
http://www.garret.ru/~knizhnik/databases.html

All freely available and open source. They all use OO paradigm, and so
will be uncomfortable for those who are not used to it.

FastDB was claimed to be really really fast. Unfortunately, it
doesn't appear as though it has seen a great deal of enhancements over
the last couple of years. It wouldn't surprise me if the recent
changes to the PG optimizer put it ahead for many cases...
--
let name="aa454" and tld="freenet.carleton.ca" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/sgml.html
Rules of the Evil Overlord #221. "My force-field generators will be
located inside the shield they generate."
<http://www.eviloverlord.com/&gt;

Bruce Momjian wrote:

PostgreSQL will not run on read-only medium easily. If you vacuum full all
the tables, that will prevent table writes, but we write to pg_clog even
for select.

You could possibly create a RAM disk, mount it, and initdb, and copy the
entire file needed for writing, and link from the RAM disk to the
read-only medium for the data files.

--
Linux homer 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386
GNU/Linux
8:00pm up 253 days, 11:21, 4 users, load average: 5.23, 5.16, 5.17