(another ;-)) PostgreSQL-derived project ... - Mailing list pgsql-general

From Albretch Mueller
Subject (another ;-)) PostgreSQL-derived project ...
Date
Msg-id CAFakBwjHhGGQ4hxWqMxWiPQo5U4DwYL=VfD7dPDn0GJ58jNThA@mail.gmail.com
Whole thread Raw
Responses Re: (another ;-)) PostgreSQL-derived project ...  (Mike Christensen <mike@kitchenpc.com>)
Re: (another ;-)) PostgreSQL-derived project ...  (David Johnston <polobo@yahoo.com>)
Re: (another ;-)) PostgreSQL-derived project ...  (Darren Duncan <darren@darrenduncan.net>)
Re: (another ;-)) PostgreSQL-derived project ...  (Uwe Schroeder <uwe@oss4u.com>)
List pgsql-general
~
 I have been searching for a PostgreSQL-derived project with a
"less-is-best" Philosophy. Even though I have read about quite a bit
of PG forks out there, what I have in mind is more like a baseline
than a fork.
~
 My intention is not wrapping the same thing in a different package or
code add-ons/value-added features on top of PG, but ridding PG of
quite a bit of its internal capabilities and just use its very
baseline.
~
 All I would need PG for is raw data warehousing, memory,
I/O-subsystem management, MVCC/transaction management ... No fanciness
whatsoever. What do you need to, say, format dates in the database if
formatting/pretty-printing and internalization can be taken care more
appropriately in the calling environment say Python or Java? All is
needed is to store a long representing the date. Why are arrays needed
in a the DB proper when serialization and marshaling/casting can be
taken care of in the calling environment. If you are using say, java,
all you need PG to do is to faithfully store a sequence of bytes and
you would do the (de)serialization very naturally indeed.
~
 There used to be a postgresql-base-<version> package with the bare
minimum of source code to build and run PostgreSQL which I think would
be a good starting point, but I don't find it in the mirror sites
anymore
~
 http://wwwmaster.postgresql.org/download/mirrors-ftp
~
 Where can I find it?
~
 I know the result will not be a SQL-compliant DBMS anymore, yet I
wonder how much faster would SQL+client code doing such things as
formatting "on-the-fly" work.
~
 Do you know of such tests even in a regular PG installation?
~
 Do you see any usefulness in such a project?
~
 Do you know of such a project? Anyone interested? Any suggestions to
someone embarking in it?
~
 It would be great if PG developers see any good in it and do it themselves ;-)
~
 lbrtchx

pgsql-general by date:

Previous
From: Eduardo Morras
Date:
Subject: Re: looking for a faster way to do that
Next
From: Rajesh Kumar Mallah
Date:
Subject: "all" not inclusive of "replication" in pg_hba.conf