Dump and Restore of Database by User

Поиск
Список
Период
Сортировка
От hubert.palme@web.de (Hubert Palme)
Тема Dump and Restore of Database by User
Дата
Msg-id 16017.59737.700517.634390@gargle.gargle.HOWL
обсуждение исходный текст
Ответы Re: Dump and Restore of Database by User
Список pgsql-bugs
Hi,

When creating a dump of a database as a user "gemein" by the command

pg_dump mitglieder >...

I get

\connect - postgres

--
-- TOC Entry ID 33 (OID 16556)
--
-- Name: "plpgsql_call_handler" () Type: FUNCTION Owner: postgres
--

CREATE FUNCTION "plpgsql_call_handler" () RETURNS opaque AS '$libdir/plpgsql', 'plpgsql_call_handler' LANGUAGE 'C';
--
-- TOC Entry ID 34 (OID 16557)
--
-- Name: plpgsql Type: PROCEDURAL LANGUAGE Owner:
--

CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER "plpgsql_call_handler" LANCOMPILER '';
\connect - gemein

...

Because of the "\connect - postgres" the user cannot reload the
database himself. On the other hand, the language PL/pgSQL is available
by default in template1, so I think those lines are unnecessary:

template1=> select * from pg_language;
 lanname  | lanispl | lanpltrusted | lanplcallfoid | lancompiler
----------+---------+--------------+---------------+-------------
 internal | f       | f            |             0 | n/a
 C        | f       | f            |             0 | /bin/cc
 sql      | f       | f            |             0 | postgres
 plpgsql  | t       | t            |         16556 |
(4 rows)

template1=>

So the user has to comment out those lines for the reload to work.

The same happens with the custom dump format, so this is unusable.

 -- Is this a bug or a feature?

 -- How can I avoid that behaviour?

I use version 7.2.1 on a Debian Linux system.

Thanks in advance,

--
Hubert Palme                           Am Walde 1
                                 42119 Wuppertal
<hubert.palme@web.de>

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

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: bug with dump sql to recreate view
Следующее
От: Ennio-Sr
Дата:
Сообщение: Re: Psql 'Expanded display (\x)' behaviour