On 12/16/2010 08:47 AM, Andrus Moor wrote:
Loading a dump file into an older server may require manual editing of
the dump file to remove syntax not understood by the older server. "
pg_restore ignores erros during restore (it only returns exit code 1).
So "manual editing of the dump file to remove syntax not understood" is
never required.
Why this is not mentioned in docs ?
That begs the question what is the problem then? If the 9.0 pg_restore
is skipping over the error there should be no problem. As to the docs,
when I have seen this besides skipping over the error pg_restore skipped
over creating the object also. This in worst case led to a cascading
problem where subsequent objects dependent on the skipped object where
not loaded either. Bottom line is you are depending on a behavior which
is documented not to be guaranteed to work. That is not going to go
away, so it would really be a good idea to come up with another
solution. This has been mentioned multiple times and now has reached the
point of beating a dead horse :)
It is the REPLACE clause that is causing the problem
How to force 9.0 to emit CREATE LANGUAGE command without replace clause ?
As far as I know you can't, it goes to the whole backwards compatibility
issue already covered. I gave you an option in the previous post re
using -l and -L switches to pg_restore.
Yea the CREATE DATABASE TEMPLATE option is as close as it gets and you
are already aware of its limitations.
How to make CREATE DATABASE TEMPLATE to work if there are connected users
to template ?
Since pg_dump works if active users are connected, CREATE DATABASE TEMPLATE
should also work.
Andrus.
At this point as I see it you have the following options:
1) Bundle version specific pg_dump/pg_restore code with your application
2) Give your users admin access. One option is phppgadmin:
http://phppgadmin.sourceforge.net/
3) An off the top of my head suggestion. Use one of the untrusted
languages to write functions that access the file system and run the
pg_restore/pg_dump programs. This would require that language be
included in each database as well as the function(s). Could be put in
template1 so subsequent databases created would pick them up. Does
create a potential security risk though.
--
Adrian Klaver
adrian.klaver@xxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
