I'm running into a minor issue with security in regards to users being able to see constructs that they have no access too.
The solution? Information_Schema coupled with no direct access to pg_catalog. Internals can use pg_catalog, possibly super users, but regular users shouldn't be able to do any reads / writes to it directly -- as per spec with definition_schema. Anyway, I'd like to start working on the information_schema and converting psql, pg_dump and other tools over to use it. After a couple of releases I'd like to block pg_catalog usage -- perhaps a GUC option? Any thoughts or objections? Obviously the information schema needs (aside from the spec) enough information to allow pg_dump to run. My thought is that if I start now when a large rewrite of clientside applications is required for schema support that there won't be nearly as much backlash later. A number of pg_dump items will be moved into base functions. Trigger statement, type formatting (various view fields). Whats the radix of the numeric, int, etc. types anyway? As a bonus, this adds a layer between the actual system tables and the clients. Might allow changes to be done easier. -- Rod Taylor Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html