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.