Re: Information/schema hiding...

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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