From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sean Chittenden <sean(at)chittenden(dot)org> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Information/schema hiding... |
Date: | 2004-04-12 12:15:42 |
Message-ID: | 8448.1081772142@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Sean Chittenden <sean(at)chittenden(dot)org> writes:
> 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.
You can't actually do that. In many (most?) situations, the search_path
value is fixed before a backend even starts; if you try to error out
because you don't like the contents, you'll prevent backends from
starting at all.
Also consider the situation where backend A creates, deletes, or changes
the permissions on schemas that are mentioned in backend B's search
path. In the existing code these cases behave consistently and much
the same as Unix PATH searching does: at all times your effective path
consists of those elements of PATH that actually exist and are readable.
It would be possible to make interactive SET behave differently from the
non-interactive case, but I don't think that would be an improvement in
understandability or usability. It's certainly not worth doing if the
only argument for changing is the one you give above.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2004-04-12 12:15:56 | Re: make == as = ? |
Previous Message | Jeroen T. Vermeulen | 2004-04-12 09:26:16 | Re: 7.5 beta version |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2004-04-12 12:36:39 | Re: COPY for CSV documentation |
Previous Message | Andrew Dunstan | 2004-04-12 12:07:12 | Re: COPY for CSV documentation |