To prevent this, I changed the
behavior of SET search_path so that it validates its input.
... It would be possible to make interactive SET behave differently
from the non-interactive case,
Wait a minute --- scratch what I said above; interactive "SET
search_path" already does behave differently f
I said:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
>> To prevent this, I changed the
>> behavior of SET search_path so that it validates its input.
> ... It would be possible to make interactive SET behave differently
> from the non-interactive case,
Wait a minute --- scratch what I said abov
Sean Chittenden <[EMAIL PROTECTED]> 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.
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 an
On Sun, 2004-04-11 at 17:10, Sean Chittenden wrote:
> 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
Sean Chittenden wrote:
Is hiding schema information a good thing? Do people think that the
concept of "secure by default" should apply to schema information
inside of the database? Should information hiding be done in psql(1)
or should this be managed by the backend and all logic kept out o
