Skip site navigation (1) Skip section navigation (2)

Re: [pgadmin-support] Schemas causing problems

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Cc: Vitaly Belman <vitalyb(at)gmail(dot)com>, pgadmin-hackers(at)postgresql(dot)org
Subject: Re: [pgadmin-support] Schemas causing problems
Date: 2004-07-27 15:16:08
Message-ID: 410671B8.3030601@pse-consulting.de (view raw or flat)
Thread:
Lists: pgadmin-hackers
Dave Page wrote:
>  
> 
> 
>>-----Original Message-----
>>From: Andreas Pflug [mailto:pgadmin(at)pse-consulting(dot)de] 
>>Sent: 26 July 2004 18:51
>>To: Dave Page
>>Cc: Vitaly Belman; pgadmin-hackers(at)postgresql(dot)org
>>Subject: Re: [pgadmin-hackers] [pgadmin-support] Schemas 
>>causing problems :(
>>
>>Dave Page wrote:
>>
>>
>>>Perhaps the search needs to be more clever though. Consider the
>>>following:
>>>
>>>search_path: public
>>>custom type: public.text
>>>
>>>In this case we might need to specify pg_catalog.text to 
>>
>>get the right 
>>
>>>one.
>>
>>This is getting a nightmare...
> 
> 
> Yup. So where are we with this? I'm thinking that for any object, we
> check each schema in the search path in turn (and then pg_catalog if
> it's not explicitly included) for an object of the same type with the
> same name (noting that sequences, tables and indexes are all effecitvely
> the same object type in this situation). If we get to the parent schema
> without first finding another matching object in a previous schema, then
> and only then do we suppress the schema name.
> 
> How does that sound?

Complicated.
Before trying to suppress the schema, I'm checking for any duplicate 
type names now. If so, schema is always emitted. In your sample: 
pg_catalog.text and public.text.

Regards,
Andreas

In response to

pgadmin-hackers by date

Next:From: Hiroshi SaitoDate: 2004-07-27 16:14:34
Subject: Assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
Previous:From: Dave PageDate: 2004-07-27 13:33:45
Subject: Re: [pgadmin-support] Schemas causing problems :(

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group