Re: Information/schema hiding...

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