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

Re: [pgadmin-support] Schemas causing problems :(

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>
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 12:34:54
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E41A7488@ratbert.vale-housing.co.uk (view raw or flat)
Thread:
Lists: pgadmin-hackers
 

> -----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?

Regards, Dave.

Responses

pgadmin-hackers by date

Next:From: Dave PageDate: 2004-07-27 13:33:45
Subject: Re: [pgadmin-support] Schemas causing problems :(
Previous:From: cvsDate: 2004-07-27 10:36:03
Subject: CVS Commit by andreas: Reworked schema prefixing

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