Should information hiding be done in psql(1) or should this be managed by the backend and all logic kept out of psql(1)?
If the intent of this feature is security, it seems totally pointless to
implement it in psql (leaving aside whether it's actually a good idea or
not).
[ WRT to search_path and nonexistent schemas ]
*nods* I completely agree that the best place for this to happen is in the backend and not psql.
Why is that needed? It's already a no-op AFAIR. It also is incompatible with the existing behavior, in which nonexistent schemas (think "$user") are dropped silently rather than noisily.
Actually, $user still works..
I think the more important question is: "Why is that needed?"
Two reasons come to mind. First, If you change your search_path to a valid schema that you have no access to and try and look for database objects, you get the impression that its an empty schema and not a schema that you don't have access to. To prevent this, I changed the behavior of SET search_path so that it validates its input. A warning may be appropriate, but I'd rather have the SET search_path fail than the CREATE [object] fail. Second, SET search_path, in my mind, is little different than ALTER TABLE ADD CONSTRAINT: it's input can be validated and permissions can be checked, therefor should it should be.
(Consider the PATH environmental var, which is fairly analogous to search_path -- that doesn't complain if you add nonexistent directories to it.)
Actually, search_path is closer in functionality to a union of the chdir(2) syscall and the PATH environment variable. Any argument to chdir(2) is validated by the operating system and chdir(2) is a system call - not a library call - for this very reason. Can you imagine a world where chdir(2) didn't validate the existence of directories as well as the permissions?
-sc
-- Sean Chittenden
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
