Joshua D. Drake wrote:
Well, that is hardly surprising. What exactly is your point?
If you want to write portable software, you usually stay with generally
available, standardized features or API's, be it "database independent",
"platform independent", you name it. You certainly don't go for
user-defined types. I really think all the nice features and
capabilities of PostgreSQL are great, but I would never, ever start
using any of them extensively in a project that might have to run on
another database. Ever heard of vendor lock-in and "embrace and expand"?
Bah! Ever heard of crappy software because of database independence?
No, actually not. I certainly heard about buggy, bad- performing
software and about software not fitting its goal, but that is mostly due
to other reasons than database independence.
I know a lot of crappy, database dependent applications.
> I have yet to see a good application that supports "database
independence".
If you are talking about high- end applications (big databases with lot
of transactions), you're of course right. However, there are a lot of
applications with small or medium sized databases and not so many
transactions, where you don't need to get the best out of your RDBMS for
decent performance.
With a good design and some expierience in portability in general, you
will be able to write a good, "quite" database independent application,
supporting some of more standardized RDBMS's.
Bye
Tim
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
