Andreas, > As Dave already pointed out, serious admin tools will avoid views. We > have to deal with version specific issues anyway.
Actually, I don't think that's what Dave said. He simply said that modifying pgAdmin to keep up with pg_catalog changes hasn't actually been a problem. And, as an increasing number of 3rd-party tools support PostgreSQL (like Embarcadero) they need a simple comprehensible API for system objects -- more objects than are included in the information_schema. I'm currently working on the integration of a major DSS tool with PostgreSQL, and we're already using the alpha version of the system views because we need them. A 3rd party proprietary vendor is not going to learn about OIDs, and they're not going to use pgAdmin. When we discussed this on this list 2 months ago, I was under the impression that extending the information_schema was verboten becuase it would break the SQL spec. If that's not the case, I personally would love to not duplicate objects. But let's establish that. -- Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match