Based on your description, I suggest you might want to look at SQLite. It
provides a number of compile-time options where you can exclude various features
you don't want from the binary, when simply ignoring the extra features isn't
good enough. -- Darren Duncan
Albretch Mueller wrote:
~
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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general