Re: [HACKERS] embedded postgresql

2004-10-20 Thread D. Richard Hipp
Christopher Browne [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]...
 
 It also seems quite curious why in-process embedding should be so
 attractive; 
 

People seem not to care whether or not the RDBMS runs in-process or
in a separately forked process.  The attribute that concerns them
is that the RDBMS is requires zero configuration. There is no separate
server process to install, configure, initialize, and administer. An
application using a zero-configuration database engine just works. 
No need to run a setup wizard to get it going.  No need to pester
your system administrator to create a new user on the database server.
Just copy over the executable, run it, and it works.

Another way to think about it is that an embedded RDBMS is not necessarily
a replacement for a traditional client/server database, but rather a
replacement for fopen() and friends accessing an ad hoc text file. Using
an embedded database is better than fopen() in that it provides a
schema layer and ACID transactions.

There are many applications for which the traditional client/server
database architecture with the server running in a separate process
is definately the best approach.  But there are just as many other
uses for which an embedded database engine works best.  For example,
an embedded database engine which stores the database in a single
orginary disk file can be used as an application file format.
The File/Open menu option creates a connection to the database file.
File/Save commits the changes.  The application reads and writes
using ordinary SQL.  Afterwards, the user can email the resulting
database to a friend.  Client/server database engines will not 
easily do this kind of stuff.

Client/server database engines clearly have their place.  But they
are not always the best solution to every data storage problem. 
Expand your horizons.

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [HACKERS] embedded postgresql

2004-10-20 Thread Christopher Browne
Clinging to sanity, [EMAIL PROTECTED] mumbled into her beard:
 I would like to know if there are any discussions about
 creating an embedded version on postgresql. My thoughts
 go towards building/porting a sqlite equivalent of pg.

People periodically drive by and suggest that PostgreSQL would
become fabulously better (or fabulously more popular) if it were
rewritten to do an in-process embedding of it.

There is little enthusiasm for the idea, as it would substantially
reduce the robustness of the system.

It also seems quite curious why in-process embedding should be so
attractive; it _looks_ as though most of the people that are so
excited about this idea have a pretty defective understanding of Unix,
and have missed the point that spawning extra processes to do
different kinds of work is a FEATURE.

The people with that defective understanding generally go away
unsatisfied.

If you really and truly want an embedded database, then you really
should look at Berkeley DB and SQLite.  They may save you a bit of
memory if you only have one application that can make use of a
database.  If you have a second application, or perhaps more than two,
it's pretty likely that linking to libpq and talking to a full-fledged
server will be a win.
-- 
(format nil [EMAIL PROTECTED] cbbrowne ntlug.org)
http://www.ntlug.org/~cbbrowne/spreadsheets.html
... it's just that in C++ and the like, you don't trust _anybody_, and
in CLOS you  basically trust everybody.  the practical  result is that
thieves and bums use C++ and nice people use CLOS.  -- Erik Naggum

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] embedded postgresql

2004-10-20 Thread Andrew Dunstan

D. Richard Hipp wrote:
Client/server database engines clearly have their place.  But they
are not always the best solution to every data storage problem. 
 

Nobody has suggested otherwise AFAICS. What we have suggested is that a 
client/server system is a bad place to start when looking for an 
embedded storage system.

Personally, I tend to use Postgres for client/server and BDB for 
embedded data management.

cheers
andrew
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] embedded postgresql

2004-10-19 Thread Steve Atkins
On Thu, Oct 14, 2004 at 09:49:47AM +0200, [EMAIL PROTECTED] wrote:
 Dear Sirs,
 
 I would like to know if there are any discussions about
 creating an embedded version on postgresql. My thoughts
 go towards building/porting a sqlite equivalent of pg.

The discussion comes up occasionally. After some well-reasoned
analysis the conclusion is generally that an embedded postgresql would
keep either none of the advantages of postgresql or would lose most of
the (single-user specific) advantages of an embedded database. Or
both.

In other words, postgresql is a really bad place to start if you want
to make an embedded database. If you search the list archives you
should find the last time this was discussed.

Cheers,
  Steve

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] embedded postgresql

2004-10-19 Thread Josh Berkus
GB:

 I would like to know if there are any discussions about
 creating an embedded version on postgresql. My thoughts
 go towards building/porting a sqlite equivalent of pg.

Not that I personally know of.While it would be nice to have an embeddable 
database which was syntax-compatible with PostgreSQL, it would be so 
radically different codewise as to be a completely different project.   
Probably the only thing you'd re-use would be the query parser code.  At a 
guess, you'd probably be better off trying to weld out query parser to 
BerkeleyDB or something than to try to downsize the PG code.

If you do, though, please let us know, and feel free to host it at pgFoundry.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


[HACKERS] embedded postgresql

2004-10-18 Thread gevik
Dear Sirs,

I would like to know if there are any discussions about
creating an embedded version on postgresql. My thoughts
go towards building/porting a sqlite equivalent of pg.

Regards,
GB.


---(end of broadcast)---
TIP 8: explain analyze is your friend


[HACKERS] Embedded postgresql

2004-10-14 Thread gevik
Dear Sirs,

I would like to know if there are any discussions about
creating an embedded version on postgresql. My thoughts
go towards building/porting a sqlite equivalent of pg.

Regards,
GB.




---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] Embedded postgresql

2004-10-14 Thread David Garamond
[EMAIL PROTECTED] wrote:
I would like to know if there are any discussions about
creating an embedded version on postgresql. My thoughts
go towards building/porting a sqlite equivalent of pg.
Yes, there have been several. Peruse the archives:
 http://archives.postgresql.org/
--
dave
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org