>FirebirdSQL and PostgreSQL both have their own liniage,įirebird derives from Interbase, so it got its start later than the others mentioned. >Dude wake up… Oracle was one of the first… >”I heard it was firebird or postgresql.” Each has its strengths, and each is improving, but I believe PostgreSQL is making faster progress these days. In fact, in the PostgreSQL mailing lists they tend to be quite sympathetic to FireBird development, as unlike another well-known open source DBMS -). Also, there are quite a few Russians and Brazilians involved in PostgreSQL, if you read the lists and browse related sites. But, at least you can get the encoding you want where you want.Īpparently PostgreSQL is quite popular in Japan, seeing as Fujitsu has undewritten quite a few of the new developments. Īlthough I will agree that it doesn’t work the standard way that I suppose IB uses. Postgres (and MySQL, I think?) still relies on OS locale facility, so it can only do per-process charset/encoding. Hm, what else am I missing? Can anybody add?īut nevertheless, Postgres is still my favorite DB 🙂 But IB/FB is like one or two decades ahead. Postgres will probably acquire this feature in 8.1?Ĥ. Two-phase commits (distributed transactions). Postgres is not embeddable, and won’t be in any near future (the Postgres developers don’t regard embedded DB as robust, so they won’t go this route for now). That is why, I guess, IB/FB is a favorite among Russians, Brazilians, etc.Ģ. In IB/FB you can set charset/encoding per table column (which is as intended by the SQL standard). IB/FB is light years ahead of Postgres in this regard. Though Postgres is progressing along at amazing speed (practically leaving other OS databases in the dust), here are a few things at which Postgres still suck or seriously lack behind other OS DB’s.ġ. At the end, it boils down to what your needs are. I love PostgreSQL, but let’s not bash Interbase/Firebird. It will be interesting to see the spin that will issue from Oracle and MySQL (for two different reasons, obviously) in dealing with this -). PostgreSQL has definitely upped the ante. Right now, PostgreSQL has essentially 3 ways, and each is conceptually different.īut, on the bright side, find the other open source DBMS that even comes close to the new PG capabilities, let alone most commercial DBMSs. Date, custom types should be handled by creation of domains, with declarative handling of composite representation, and there should be no need of other mechanisms.
It is quite confusing, with (I think) a wrong concept of what a “composite” type should be (they equate it to a set-returning table expression), when the actual implementation of true composite types is left to low-level type creation with C structs, and procedural declaration of functions to handle representation, etc … True custom datatypes in PostgreSQL are still subject to “procedural” thinking, and in fact are only easy if you are a C programmer. For example, CREATE TYPE does two completely different things, depending on the parameters you use. The other big thing I would like to see in PostgreSQL right now is a much better/consistent approach to user-defined types and domains.
#Pgadmin 4 not opening full
AFAIK, Oracle is the only system which has these capabilities in full (see this). Look for “Don’t be Lazy: be Consistent”, by Kemme, which is the seminal research paper on this for PostgreSQL. Google for “Postgres-R eager” and you will see some interesting links. This is also called “eager” replication, and there was an older PostgreSQL project that implemented this for awhile on PostgreSQL 6.5, and there were some attempts to port it to PG 7 back in 2002, but it seems to have been abandoned. Imagine having a group of servers distributed anywhere you want geographically, and being able to write a transaction to any machine, without worrying whether a transaction will be lost in limbo. This is the holy grail of database replication. But there is no current support for multi-master/multi-slave with automatic conflict resolution. Multi-master eager replication – with PostgreSQL, the two approaches to replication right now are synchronous master/slave, and asynchronous single-master/multi-slave. IMHO there are only two areas that I would really like to see future progress on: As I mentioned, I think these are great steps forward for PostgreSQL.
0 kommentar(er)
