Re: Schemas causing problems :(

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: Schemas causing problems :(
Дата
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E41A7443@ratbert.vale-housing.co.uk
обсуждение исходный текст
Ответ на Schemas causing problems :(  (Vitaly Belman <vitalyb@gmail.com>)
Список pgadmin-support

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 26 July 2004 14:41
> To: Vitaly Belman
> Cc: pgadmin-support@postgresql.org; Dave Page
> Subject: Re: [pgadmin-support] Schemas causing problems :(
>
>
> Dave, this problem originates from
> pgDatabase::GetSchemaPrefix removing the schema if it's on
> the search_path. AFAIR you arose the problem of search_path,
> but now I see that I changed it myself. It's obviously a
> mistake to suppress the schema when creating/modifying
> objects (unless public or pg_catalog), can you think of a
> situation *at all* that we might want to evaluate that in pgAdmin3?

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

Vitaly's problem is another good example of course.

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.

Regards, Dave.


В списке pgadmin-support по дате отправления:

Предыдущее
От: Andreas Pflug
Дата:
Сообщение: Re: Schemas causing problems :(
Следующее
От: Duane Winner
Дата:
Сообщение: Re: pgadmin3 on freebsd