>> 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