| 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: | Whole Thread | Raw Message | 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 |