Bruce Momjian writes:
> Should pg_dumpall be using the "SET default_tablespace = foo" method as
> well?
That would mean changing the semantics of CREATE DATABASE; currently it
copies the default tablespace from the template database, rather than
looking at default_tablespace. I'm unsure if that'
Florian G. Pflug wrote:
Chander Ganesan wrote:
Tom Lane wrote:
Chander Ganesan <[EMAIL PROTECTED]> writes:
I'd like to suggest that a feature be added to pg_dumpall to remove
tablespace definitions/creation from the output. While the
inclusion is important for backups - it's equally painfu
Should pg_dumpall be using the "SET default_tablespace = foo" method as
well?
---
Florian G. Pflug wrote:
> Chander Ganesan wrote:
> > Tom Lane wrote:
> >> Chander Ganesan <[EMAIL PROTECTED]> writes:
> >>
> >>> I'd like to
Chander Ganesan wrote:
Tom Lane wrote:
Chander Ganesan <[EMAIL PROTECTED]> writes:
I'd like to suggest that a feature be added to pg_dumpall to remove
tablespace definitions/creation from the output. While the inclusion
is important for backups - it's equally painful when attempting to
mig
Tom Lane wrote:
Chander Ganesan <[EMAIL PROTECTED]> writes:
I'd like to suggest that a feature be added to pg_dumpall to remove
tablespace definitions/creation from the output. While the inclusion is
important for backups - it's equally painful when attempting to migrate
data f
Chander Ganesan <[EMAIL PROTECTED]> writes:
> I'd like to suggest that a feature be added to pg_dumpall to remove
> tablespace definitions/creation from the output. While the inclusion is
> important for backups - it's equally painful when attempting to migrate
> data from a development to prod
I'd
like to suggest that a feature be added to pg_dumpall to remove
tablespace definitions/creation from the output. While the inclusion
is important for backups - it's equally painful when attempting to
migrate data from a development to production database. Since
PostgreSQL won't create the
