> doesn't rely on proprietary solutions. no proprietary solution is involved, really, as PostgreSQL is nearly as close to the SQL standard as one gets
But SQL doesn't support inheritance, does it? I thought that is what you were trying to get to work and were using PostgresSQL extensions for that purpose.
> A lot of this work is trying to > reproduce object oriented approaches we aren't reproducing much of anything (in the database, that is) but rather try to avoid falling into the traps I pointed out
> Simply use those > solutions rather than trying to figure it out for a given database engine.
Not really, as most of these features are supported by some of the available (open source)
mapping tools, so that you don't have to do this yourself and can maintain DBMS portability.
Some of these features as being non-standard create problems of portability, but most of them
are accommodated by Object-Relational mapping tools. Take a look at things
like ojb from Apache, for example. (http://db.apache.org)
Dave
I take it this is not to mean that I shouldn't rely on transactions, nested selects in where clauses, triggers, stored procedures, foreign keys, views and check constraints either because some deficient database engines don't support them ?
Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
