Re: pgdump

Поиск
Список
Период
Сортировка
От Andreas Tille
Тема Re: pgdump
Дата
Msg-id Pine.LNX.4.21.0009201053530.1078-100000@wr-linux02.rki.de
обсуждение исходный текст
Ответ на Re: pgdump  ("Ross J. Reedstrom" <reedstrm@rice.edu>)
Список pgsql-general
On Tue, 19 Sep 2000, Ross J. Reedstrom wrote:

> I'd guess that Andreas must have looked at the template1 database with
> pgaccess.
Yes, this was the reason.

> That would create the pga_* tables in there, which would then
> propagate to all newly crreated dbs. Pgaccess makes these files behind
> the users back.  It might be reasonable for it _not_ to create them in
> template1, if possible, without prompting the user, at least. I'll ask
> Constantin about it.
That's a nice idea!

This reminds me to a further issue on this topic:
By accident I filed a dump not to the intended database, but to
template1.  This is not hard to do because I wrote a script like

#!/bin/sh
MYDB=<some_function>
cat dumpfile | psql $MYDB

unfortunately I hadn't checked whether $MYDB could be "" :-(.

So I filled my template1 database with a lot of rubish.
Nice exercise to remove this rubish which introduced me a little bit
deeper into PostgreSQL internal tables :).  Hope that I got rid off
all this stuff.

So the idea is to make it a little bit harder to put something into
template1 or, alternatively serve a method which helps out such kind
of situation.

.... just an idea ...

> The workaround is to go into template1 with psql and drop the pga_*
> tables, then never use pgaccess to look in there.
Or just to call my script which removes all tables and sequences
which are not created by user postgres :).

Kind regards

         Andreas.


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

Предыдущее
От: Andrew.Mason@spektra.co.uk
Дата:
Сообщение: Specifying date locales
Следующее
От: Zeljko Trogrlic
Дата:
Сообщение: RE: Latest JDBC Driver? Where?