Bruce Momjian writes:
> Oh, I see what you mean. I was just worried that some code might expect
> template1 to always have an oid of 1, but we can just call that code
> broken.
Ever since we invented template0, it's been possible to drop and recreate
template1, so I'd say any expectation that it
On Sun, Jan 21, 2018 at 11:02:29AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Jan 19, 2018 at 02:54:25PM -0500, Tom Lane wrote:
> >> Command was: DROP DATABASE "template1";
>
> > Uh, the oid of the template1 database is 1, and I assume we would want
> > to preserve that too.
>
>
I've been hacking away at this patch, and attached is what I've got
so far. I think this is committable, but if anyone wants to do
further review and testing, that'd be fine.
Per discussion, I got rid of the separate --set-db-properties switch:
additional database properties are now applied if an
Bruce Momjian writes:
> On Fri, Jan 19, 2018 at 02:54:25PM -0500, Tom Lane wrote:
>> Command was: DROP DATABASE "template1";
> Uh, the oid of the template1 database is 1, and I assume we would want
> to preserve that too.
I don't feel any huge attachment to that. In the first place, under
this
On Fri, Jan 19, 2018 at 02:54:25PM -0500, Tom Lane wrote:
> Hmm ... so there's a small problem with this idea of dropping and
> recreating template1:
>
> pg_restore: connecting to database for restore
> pg_restore: dropping DATABASE template1
> pg_restore: [archiver (db)] Error while PROCESSING TO
Robert Haas writes:
> On Fri, Jan 19, 2018 at 2:54 PM, Tom Lane wrote:
>> What do people think of just removing this DROP DATABASE restriction?
>> Arguably, superusers should know better than to drop template1 anyway.
>> Maybe we should replace it with a hard-wired check against dropping
>> templ
On Fri, Jan 19, 2018 at 2:54 PM, Tom Lane wrote:
> Hmm ... so there's a small problem with this idea of dropping and
> recreating template1:
>
> pg_restore: connecting to database for restore
> pg_restore: dropping DATABASE template1
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_r
Hmm ... so there's a small problem with this idea of dropping and
recreating template1:
pg_restore: connecting to database for restore
pg_restore: dropping DATABASE template1
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3024; 1262 1 DATAB
Robert Haas writes:
> On Fri, Jan 19, 2018 at 10:00 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane wrote:
Well, we could say that the properties of template1 and postgres
are only restored if you use --clean.
>>> True. Would that be a POLA v
On Fri, Jan 19, 2018 at 10:00 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane wrote:
>>> Well, we could say that the properties of template1 and postgres
>>> are only restored if you use --clean.
>
>> True. Would that be a POLA violation, do you think?
>
>
Robert Haas writes:
> On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane wrote:
>> Well, we could say that the properties of template1 and postgres
>> are only restored if you use --clean.
> True. Would that be a POLA violation, do you think?
It seems a bit non-orthogonal. Also, while your point that
On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 18, 2018 at 6:35 PM, Tom Lane wrote:
>>> If we did it like that, the rationale for an actual --set-db-properties
>>> switch would vanish, at least so far as pg_dumpall is concerned -- we
>>> could just make all
Robert Haas writes:
> On Thu, Jan 18, 2018 at 6:35 PM, Tom Lane wrote:
>> If we did it like that, the rationale for an actual --set-db-properties
>> switch would vanish, at least so far as pg_dumpall is concerned -- we
>> could just make all that behavior an integral part of --create. And
>> thi
On Thu, Jan 18, 2018 at 6:35 PM, Tom Lane wrote:
> If we did it like that, the rationale for an actual --set-db-properties
> switch would vanish, at least so far as pg_dumpall is concerned -- we
> could just make all that behavior an integral part of --create. And
> this wouldn't need to be condi
On Fri, Jan 19, 2018 at 10:35 AM, Tom Lane wrote:
> I wrote:
> > What I think we should do for the time being is to have pg_dump treat
> > database tablespace as a property it can't adjust after creation, just
> > as it can't adjust locale or encoding. That's a loss of functionality
> > for pg_d
I wrote:
> What I think we should do for the time being is to have pg_dump treat
> database tablespace as a property it can't adjust after creation, just
> as it can't adjust locale or encoding. That's a loss of functionality
> for pg_dumpall/pg_upgrade compared to where we are today, in that if
>
... okay, so the reason why --set-db-properties isn't as general-purpose
a switch as you might think finally penetrated my thick skull :-(
The problem is that, as the patch is currently constituted, that will
result in emitting a lot of "ALTER DATABASE foo" type commands. If
somebody tries to loa
Robert Haas writes:
> On Wed, Jan 17, 2018 at 6:50 PM, Tom Lane wrote:
>> * As the patch stands, --set-db-properties is implicit when you specify
>> -C, and in fact the patch goes to the trouble of throwing an error if you
>> try to specify both switches. I'm inclined to think this might be a ba
On Wed, Jan 17, 2018 at 6:50 PM, Tom Lane wrote:
> * As the patch stands, --set-db-properties is implicit when you specify
> -C, and in fact the patch goes to the trouble of throwing an error if you
> try to specify both switches. I'm inclined to think this might be a bad
> idea. What about sayi
Haribabu Kommi writes:
> [ pg_dump-and-pg_dumpall-database-handling-refactoring_v12.patch ]
I've gone through this in a once-over-lightly fashion. Since there was
quite a bit of debate upthread about how things should work, I'd like
to start by summarizing the decisions this patch has made, in c
On Thu, Jan 18, 2018 at 8:25 AM, Tom Lane wrote:
> Haribabu Kommi writes:
> > [ pg_dump-and-pg_dumpall-database-handling-refactoring_v12.patch ]
>
> I started to look through this, and almost immediately found that the
> diff in t/002_pg_dump.pl doesn't seem necessary --- the test passes
> for m
Haribabu Kommi writes:
> [ pg_dump-and-pg_dumpall-database-handling-refactoring_v12.patch ]
I started to look through this, and almost immediately found that the
diff in t/002_pg_dump.pl doesn't seem necessary --- the test passes
for me without applying that hunk. Is that a leftover from a previ
On Fri, Jan 5, 2018 at 4:32 PM, Haribabu Kommi
wrote:
>
>
> Corrected.
> Updated patch attached.
>
> Moved this CF item to "Ready for committer"
Regards,
Vaishnavi,
Fujitsu Australia.
On Fri, Jan 5, 2018 at 2:54 PM, Vaishnavi Prabakaran <
vaishnaviprabaka...@gmail.com> wrote:
>
> On Wed, Dec 13, 2017 at 1:50 PM, Haribabu Kommi
> wrote:
>
>> Rebased patch attached that fixes the documentation build problem.
>>
>> Latest patch applies without noise. And here are some minor comme
On Wed, Dec 13, 2017 at 1:50 PM, Haribabu Kommi
wrote:
> Rebased patch attached that fixes the documentation build problem.
>
> Latest patch applies without noise. And here are some minor comments
+
+ --set-db-properties
+
+
+This option is to skip create database
On Wed, Nov 29, 2017 at 4:25 PM, Michael Paquier
wrote:
> On Wed, Nov 8, 2017 at 8:50 AM, Haribabu Kommi
> wrote:
> > Ok. Removed the documentation changes that it cannot be used for normal
> > scenarios, and also added a Note section explaining the problem of using
> > the dump with pg_restore
On Wed, Nov 8, 2017 at 8:50 AM, Haribabu Kommi wrote:
> Ok. Removed the documentation changes that it cannot be used for normal
> scenarios, and also added a Note section explaining the problem of using
> the dump with pg_restore command with --clean and --create options.
Hari, the documentation
27 matches
Mail list logo
