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-26 17:09:21
Message-ID: 41053AC1.50009@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Dave Page wrote:
>
>
>
>>-----Original Message-----
>>From: Andreas Pflug [mailto:pgadmin(at)pse-consulting(dot)de]
>>Sent: 26 July 2004 17:28
>>To: Dave Page
>>Cc: Vitaly Belman; pgadmin-hackers(at)postgresql(dot)org
>>Subject: Re: [pgadmin-support] Schemas causing problems :(
>>
>>This is really hackers stuff.
>>
>>
>>Dave Page wrote:
>>
>>>
>>>I don't recall that discussion, but in general I think we should
>>>completely ignore the search path. Consider a function:
>>
>>foo.dostuff().
>>
>>>The current code will return an empty schema prefix for a
>>
>>search_path
>>
>>>of public,bar,foo. What if there is also public.dostuff()
>>
>>or bar.dostuff()?
>>
>>>CREATE OR REPLACE could really screw up in that case...
>>
>>Some logic black holes... preliminarily public only.
>
>
> Public only would work fine unless the user had an object in pg_catalog
> (not advisable, but when did that stop some ppl)...
>
>
>>>I also don't like the notion of treating public as some kind of
>>>special schema. From PostgreSQL's pov, its only special in
>>
>>that it's
>>
>>>there by default in template1 and the search_path. Other than that
>>>it's just another schema and should be treated as such.
>>
>>A grep showed that only FK has handles public special, all
>>other places go through pgDatabase::GetSchemaPrefix.
>
>
> Yeah - I thought you were implying treating public/pg_catalog
> differently when you said "It's obviously a mistake to suppress the
> schema when creating/modifying objects (unless public or pg_catalog)"
>
>
>>The correct overall behaviour seems
>>
>>- find the first schema in search_path that exists.
>>- If this is the schema in question, suppress it.
>
>
> OK. Still might result in broken reverse engineered SQL when used in a
> different session with a different search path of course.
>
>
>>- (ignore all following schema names, this was the main problem)
>
>
> Yup.
>
>
>>- If schema = pg_catalog, suppress it.
>
>
> Why? Any reverse engineered SQL will then incorrectly force objects into
> the first existing schema in the search_path, not pg_catalog.

pg_catalog is read-only (well, usually...), and displays only
optionally. When context menu is reworked, we should disable
creation/modification too.

>
>>Unfortunately, this search_path[i] = session_user is not
>>absolutely stable (schema or user name may change), but it
>>should be stable enough.
>>
>>Thoughts?
>
>
> Fully qualify everything.

You'd wipe your eyes if we really did. How do you like pg_catalog.int4,
pg_catalog.text and so forth? <shrug>

> I think it's the only truly infallible way.

And the ugliest.
Maybe we should invent a switch if default schema suppression is not
wanted; the search path option seems useless.

Regards,
Andreas

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message Vitaly Belman 2004-07-26 17:20:36 Re: [pgadmin-support] Schemas causing problems :(
Previous Message Andreas Pflug 2004-07-26 16:27:49 Re: [pgadmin-support] Schemas causing problems :(