Subject PostgreSQL observation (Is Firebird progressing adequately?)
Author David Garamond
Today I spent half an hour browsing through PostgreSQL ("PG") webpages
and mailing list archives. I first evaluated PG about 2-3 years ago, and
decided it was not suitable for my projects because of three main
reasons: a) no native win32 port; b) no 2-phase commit; c) perceived
kludge/complexity (e.g. 'template1' and complex configuration/directory
structures vs nice single DB file in IB/FB).

I am quite surprised to see that PG has been progressing quite a lot.
When 7.4 was released I read that native Windows port (threaded/"SS" and
all) is almost complete and will "definitely" go into 7.5. 7.5 will
probably also include 2-phase commit support (maybe with even an
XA-compliant API), there are already two separate working patches for
7.3 and 7.4 to do 2PC. And I believe as soon as the threaded variant of
PG server is being used, people will start asking for embedded version.
Hopefully the PG team will simplify configuration/etc when adding
embedded support.

I remember the days in the 6.x series when PG didn't even have
generational (they call it MVCC) architecture and it was constantly
being ridiculed as slow (especially compared to MySQL).

In short, PG has been catching up in areas where FB used to be my only
alternative. I will have to reconsider PG again for future projects
(probably when 7.5 is actually released with a stable win32 port). I
believe others will do the same, especially since PG has some nice
features that FB currently lacks/doesn't have (and probably will never
have :-) ) such as:

- freely available (BSD licensed) replication and full-text search solution;
- a much-richer data types support (for example: arbitrary precision
numbers, geometry data types, bit strings) which is certainly convenient
for some classes of apps;
- WAL;
- monitoring (FB2 is supposed to do this too though);
- flexible authentication (FB2 too?);
- current version of PG can run on older glibc (RH7.x), while FB1.5
demands newer distro (like RH8 & RH9);
- writing stored procedures in your favorite language (Ruby and Perl,
for example :-));
- "object-relational" features (i'm not interested at all with this though);
- 3rd party languages support, especially in the Unix world (I currently
can't find up-to-date FB library for Ruby, Perl, PHP; though that is
understandable since FB and even IB is still rather new in the open
source arena);
- index on expressions and partial index (though of course you can also
do this in FB via a workaround);

So what's the point of this post? Nothing I guess :-) But as an outsider
(non-developer of FB) I wonder what generally makes us not progressing
as fast as PG (or dare I say IB7.x), because frankly judging from the
mailing lists traffic alone FB can be considered very, very active :-)
Is it mainly because the long and painful migration to C++? Is IB7.x
codebase still in C?

--
dave