Обсуждение: Dropping wrong object

I thought I had seen this reported before, but I'm not finding it, so
here goes ...

If an object of the same name exists in the user[1] and the public
schema, then using the delete/drop command on the object in the public
schema in pgadmin3 (1.2.0) can cause the wrong object to be dropped. 
The cause seems to be not including the schema name in the drop
command when the schema is public.  Since the default search path puts
the user's schema before the public one, this will drop the wrong item
in the default config.  And who knows what the user might set the
default search path to in the postgresql.conf.

[1] i.e. the schema with the same name as the logged in user

--    -- Cheetah

Cheetah wrote:
> I thought I had seen this reported before, but I'm not finding it, so
> here goes ...
> 
> If an object of the same name exists in the user[1] and the public
> schema, then using the delete/drop command on the object in the public
> schema in pgadmin3 (1.2.0) can cause the wrong object to be dropped. 
> The cause seems to be not including the schema name in the drop
> command when the schema is public.  Since the default search path puts
> the user's schema before the public one, this will drop the wrong item
> in the default config.  And who knows what the user might set the
> default search path to in the postgresql.conf.
> 
> [1] i.e. the schema with the same name as the logged in user

I hate search_path....

I think we should add an option to suppress the public. prefix if 
desired. This may be on by default if no $user (or other schema 
preceding public in search_path) exists.
It's in BUGS.txt now.

Regards,
Andreas

On Fri, 28 Jan 2005 13:45:02 +0000, Andreas Pflug
<pgadmin@pse-consulting.de> wrote:
> I hate search_path....

Well, on average it's been quite useful for me, but that's neither
here nor there.

> I think we should add an option to suppress the public. prefix if
> desired. This may be on by default if no $user (or other schema
> preceding public in search_path) exists.
> It's in BUGS.txt now.

Sorry if I'm misunderstanding something, but it seems that the
solution is to *always* put in the schema prefix, unless the server is
an old enough version that it doesn't support schema.  The suppression
of the public. prefix is what's causing the problem I experienced.

--    -- Cheetah