> there are several abstraction layers. I could use some ODBC-API, but
> this wouldn't help. I do something like 'select ... from pg_class where
> ...' and so on. If the target database has no pg_class or pg_attribute
> or pg_whatsoever-systemtable, it wouldn't help, if I could send my query
> to the database. I would like to show everything the
> PostgreSQL-systemtables will give me. I could try to do some
> abstraction, but I doubt other databases could give me exactly the
> information PostgreSQL does. I'm sure MySQL and Oracle and other
> Databasesystems have much information in their systemtables, but not
> exactly the same as Pg.
For what it's worth, I agree with this statement. The way I see it, what is
great about getting a more advanced PostgreSQL GUI is that it is specifically
designed for postgres. I am sure there are a few graphical tools out there
that already try to be DB-independant... but then you never get the features
that make the database great. In other words, don't go for the lowest common
denominator, because I would like to create things that don't necessarily
work as well in MySQL or whatever other databases are part of the abstraction
layer.
However, it would certainly make sense to use those abstraction layers for
tasks common across many databases. This would just be considered good
programming practice since it doesn't usually take much more work. Moreover,
you can use these standard calls to import and export data from another DB.
I.E. if you were to make a generic import you could use an abstracted layer
to perform a simple select statement to work accross all DBs.
In short, don't let an abstraction layer get in the way of what you really
want to do.
Thanks!
Best regards,
Jeff
