Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > ALTER DATABASE ... SET seems to be something that doesn't fit in
> > anywhere; I am thinking pg_dump -g should dump it.
>
> The upthread conclusion was that pg_dump -C should do it.
> I am not sure how you come to the conclusion that
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ALTER DATABASE ... SET seems to be something that doesn't fit in
> anywhere; I am thinking pg_dump -g should dump it.
The upthread conclusion was that pg_dump -C should do it.
I am not sure how you come to the conclusion that -g is an
appropriate place,
Robert Treat wrote:
> On Thursday 21 August 2008 18:28:55 Bruce Momjian wrote:
> > We never came up with any idea of how pg_dump could dump ALTER DATABASE
> > ... SET commands, so I have added a mention in the documentation, and
> > backpatched to 8.3.X; attached.
> >
>
> ok, I have no recollecti
On Thursday 21 August 2008 18:28:55 Bruce Momjian wrote:
> We never came up with any idea of how pg_dump could dump ALTER DATABASE
> ... SET commands, so I have added a mention in the documentation, and
> backpatched to 8.3.X; attached.
>
ok, I have no recollection of this conversation :-)
but..
We never came up with any idea of how pg_dump could dump ALTER DATABASE
... SET commands, so I have added a mention in the documentation, and
backpatched to 8.3.X; attached.
---
Richard Huxton wrote:
> Robert Treat wrote:
>
Robert Treat wrote:
On Tuesday 01 July 2008 03:45:44 Richard Huxton wrote:
The only time we need to restore per-database settings is if the
database has been dropped. If you're not having the dump/restore
re-create the database then presumably you've taken charge of the
per-database settings.
On Tuesday 01 July 2008 03:45:44 Richard Huxton wrote:
> Tom Lane wrote:
> > Richard Huxton <[EMAIL PROTECTED]> writes:
> >> Tom Lane wrote:
> >>> So put forward a worked-out proposal for some other behavior.
> >>
> >> IMHO the time a dump/restore should be issuing ALTER...SET on a database
> >> is
Tom Lane wrote:
Richard Huxton <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
So put forward a worked-out proposal for some other behavior.
IMHO the time a dump/restore should be issuing ALTER...SET on a database
is when it has issued the corresponding CREATE DATABASE.
So pg_dump would produc
Richard Huxton <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So put forward a worked-out proposal for some other behavior.
> IMHO the time a dump/restore should be issuing ALTER...SET on a database
> is when it has issued the corresponding CREATE DATABASE.
So pg_dump would produce this info w
Tom Lane wrote:
So put forward a worked-out proposal for some other behavior.
OK
My first thought is that the -c and -C options create a lot of the
issues in this area. -c in particular is evidently meant for merging a
dump into a database that already contains unrelated objects. (In fact
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Robert Treat wrote:
>> Certainly not desired by a number of people I have talked to, but I don't
>> have
>> much hope in seeing the behavoir change... perhaps someday if we get around
>> to merging pg_dump and pg_dumpall
> I have never heard anyo
Robert Treat wrote:
> On Friday 27 June 2008 12:58:41 Richard Huxton wrote:
> > > Am I doing something stupid here?
> >
> > OK - so to get the ALTER DATABASE commands I need to dump the schema for
> > the entire cluster. Is that really desired behaviour?
>
> Certainly not desired by a number of p
On Friday 27 June 2008 12:58:41 Richard Huxton wrote:
> Richard Huxton wrote:
> > Richard Huxton wrote:
> >> At present it means you can't reliably do:
> >> DROP DATABASE foo;
> >> pg_restore --create foo.dump
> >> I'd then have to either hand edit the dumpall dump or wade through a
> >> bunch of
Richard Huxton wrote:
Richard Huxton wrote:
At present it means you can't reliably do:
DROP DATABASE foo;
pg_restore --create foo.dump
I'd then have to either hand edit the dumpall dump or wade through a
bunch of errors checking that none of them were relevant.
Actually, I'm not sure pg_dum
Richard Huxton wrote:
At present it means you can't reliably do:
DROP DATABASE foo;
pg_restore --create foo.dump
I'd then have to either hand edit the dumpall dump or wade through a
bunch of errors checking that none of them were relevant.
Actually, I'm not sure pg_dumpall does them either.
15 matches
Mail list logo
