I'm not really keen on this idea unless you're eager to make a 5-year
commitment to maintain the code. The load formats of other RDBMSes change
all the time -- MySQL is a particularly egregious example, with 2
incompatible changes in the last year -- and it would become a pain to keep
track.
Chris,
> I was thinking a pg_export utility that can output to a range of other
> databases SQL formats would also be a good idea. It would share about
> 90% of the pg_dump code, but I'm trying to think of how to avoid
> duplicating the code.
I'm not really keen on this idea unless you're eager
Christopher Kings-Lynne wrote:
I've been looking at this for a while now, and will probably give it
a go for 7.6/8.
Let me know when you do, I'd be interested in collaborating.
Command Prompt, if would help could help sponsor this project.
Sincerely,
Joshua D. Drake
Chris
--
Command Prompt, Inc
At 02:00 PM 3/08/2004, Christopher Kings-Lynne wrote:
I'd be interested in collaborating.
Sounds good.
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498)
I've been looking at this for a while now, and will probably give it a
go for 7.6/8.
Let me know when you do, I'd be interested in collaborating.
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
At 01:17 PM 3/08/2004, Christopher Kings-Lynne wrote:
Would be a bit of work though.
I've been looking at this for a while now, and will probably give it a go
for 7.6/8.
Philip Warner| __---_
Albatross C
Another reason to combine pg_dumpall into pg_dump...
No argument here. Are you thinking of that?
Yeah. Would be a bit of work though.
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Chris,
> Another reason to combine pg_dumpall into pg_dump...
No argument here. Are you thinking of that?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you searched our list archives?
I find this behavior highly undesirable, and consider it a bug.The
globals dump should just add users, and not delete any.
Unless the --clean option is passed, yes I agree with you. The other
issue is that it is silly to have to use pg_dumpall to get the globals.
A person should be able to
AFAICS that happens only if you've specified the -c (--clean) option.
Hence, I don't think it's a bug.
Nope, happens even if you don't pass --clean.
Not in CVS tip ... but you're right, older versions did act that way.
Looks like someone addressed this already.
Yeah, was one of my fixes.
Should w
I've just found a bit of undesirable functionality which I would call a bug in
pg_dump. I'm not sure everyone would, but we'll see.
Problem: the script which dumps globals such as users (pg_dumpall -g)
involves deleting *all* users from the pg_shadow table via a direct update to
that table.
Josh Berkus <[EMAIL PROTECTED]> writes:
>> AFAICS that happens only if you've specified the -c (--clean) option.
>> Hence, I don't think it's a bug.
> Nope, happens even if you don't pass --clean.
Not in CVS tip ... but you're right, older versions did act that way.
Looks like someone addressed t
On Mon, 2 Aug 2004, Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
Problem: the script which dumps globals such as users (pg_dumpall -g)
involves deleting *all* users from the pg_shadow table via a direct update to
that table.
AFAICS that happens only if you've specified the -c (--clean)
Tom,
> AFAICS that happens only if you've specified the -c (--clean) option.
> Hence, I don't think it's a bug.
Nope, happens even if you don't pass --clean.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 5
This is a non-trivial accident to have happen on a shared machine; once users
are dumped, all of their ownerships and permissions go with them. If you
have a complex permissions system, better hope you backed up first!
I find this behavior highly undesirable, and consider it a bug.The glo
Josh Berkus <[EMAIL PROTECTED]> writes:
> Problem: the script which dumps globals such as users (pg_dumpall -g)
> involves deleting *all* users from the pg_shadow table via a direct update to
> that table.
AFAICS that happens only if you've specified the -c (--clean) option.
Hence, I don't think
Chris,
I've just found a bit of undesirable functionality which I would call a bug in
pg_dump. I'm not sure everyone would, but we'll see.
Problem: the script which dumps globals such as users (pg_dumpall -g)
involves deleting *all* users from the pg_shadow table via a direct update to
that
KL,
> CREATE DATABASE phppgadmin WITH TEMPLATE = template0 OWNER = chriskl
> ENCODING = 'LATIN1';
> CREATE DATABASE usa WITH TEMPLATE = template0 OWNER = usadmin ENCODING =
> 'LATIN1';
Ok, so that would come under the heading of "already fixed". Great.
--
Josh Berkus
Aglio Database Solutions
S
In article <[EMAIL PROTECTED]>,
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Mon, 2004-07-19 at 12:36, Josh Berkus wrote:
>> Rod,
>>
>> > I think what we want is a clean template without all of the extras that
>> > template1 has.
>>
>> We have this, it's called Template0.
> Doesn't work for me.
On Mon, 2004-07-19 at 21:20, Christopher Kings-Lynne wrote:
> > We already are to some extent, since pg_dump will dump its comment and
> > privileges, which it would not do for any other predefined object.
> > I think this is actually an implementation artifact rather than
> > something that was ex
Actually, KL, that would solve a lot of these duplicate object problems. What
if pg_restore used Template0 and not Template1?It wouldn't fix the "drop
public schema" issue but it would solve the others.
Not sure what you mean here, but CVS pg_dump dumps like this:
CREATE DATABASE phppgadmin
We already are to some extent, since pg_dump will dump its comment and
privileges, which it would not do for any other predefined object.
I think this is actually an implementation artifact rather than
something that was explicitly intended at the time, but since no one
has complained about it, it'
On Mon, 2004-07-19 at 13:30, Josh Berkus wrote:
> Rod,
>
> > Remove the public schema from template0, but leave it in template1. Have
> > pg_dump treat the public schema the same as all of the other ones.
>
> Hmmm. No good; it wipes out the primary purpose of Template0, which is to
> restore a
Rod,
> Remove the public schema from template0, but leave it in template1. Have
> pg_dump treat the public schema the same as all of the other ones.
Hmmm. No good; it wipes out the primary purpose of Template0, which is to
restore a corrupted Template1.
--
-Josh Berkus
Aglio Database Solutio
Rod Taylor <[EMAIL PROTECTED]> writes:
> Remove the public schema from template0, but leave it in template1.
Does not sound very workable. One of the functions of template0 is to
be a backup for the virgin state of template1, and you'd lose that.
regards, tom lane
--
On Mon, 2004-07-19 at 12:36, Josh Berkus wrote:
> Rod,
>
> > I think what we want is a clean template without all of the extras that
> > template1 has.
>
> We have this, it's called Template0.
Doesn't work for me. I remove a number of things that are included by
default in template0, but yes, it
Rod,
> I think what we want is a clean template without all of the extras that
> template1 has.
We have this, it's called Template0.
Actually, KL, that would solve a lot of these duplicate object problems. What
if pg_restore used Template0 and not Template1?It wouldn't fix the "drop
publi
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I think that we should treat the public schema specially :)
We already are to some extent, since pg_dump will dump its comment and
privileges, which it would not do for any other predefined object.
I think this is actually an implementation art
On Sun, 2004-07-18 at 23:55, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I think what we want is a clean template without all of the extras that
> > template1 has.
>
> Sounds like a job for ... template0 !
It doesn't quite work in my case as I've removed items included in
templat
Sounds like a job for ... template0 !
Seriously, this thread would be more convincing if anyone in it betrayed
any knowledge that pg_dump wants you to start from template0 rather than
template1.
What if we made it so that template1 is always restored last? Won't
that be an improvement?
Chris
---
Rod Taylor <[EMAIL PROTECTED]> writes:
> I think what we want is a clean template without all of the extras that
> template1 has.
Sounds like a job for ... template0 !
Seriously, this thread would be more convincing if anyone in it betrayed
any knowledge that pg_dump wants you to start from templ
No, because pg_dump itself dumps template1's contents...
Are you planning on extending this line of thought to other things in
template1 such as operators?
Ah, I see where you are going with this
I think that we should treat the public schema specially :) That's
because it is much more likely
On Sun, 2004-07-18 at 07:42, Christopher Kings-Lynne wrote:
> > I am not sure that is really a bug. If someone really wants less than
> > what is in template1, they should be dropping stuff from template1
> > before recreating the database.
>
> No, because pg_dump itself dumps template1's contents
On Sun, Jul 18, 2004 at 19:42:09 +0800,
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> >I am not sure that is really a bug. If someone really wants less than
> >what is in template1, they should be dropping stuff from template1
> >before recreating the database.
>
> No, because pg_dump its
I am not sure that is really a bug. If someone really wants less than
what is in template1, they should be dropping stuff from template1
before recreating the database.
No, because pg_dump itself dumps template1's contents...
Chris
---(end of broadcast)--
On Sun, Jul 18, 2004 at 14:33:09 +0800,
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
>
> * If you drop your public schema, a drop command is not issued for it in
> the dump, so when you restore your public schema is back
I am not sure that is really a bug. If someone really wants less th
Hi everyone,
I've decided to attempt to nail all known bugs in pg_dump for 7.5 :)
So, please send me ALL your known bugs/issues with pg_dump, pg_dumpall
and pg_restore. Note that I am NOT interested in feature requests, ONLY
bugs.
A bug is considered to be an issue in pg_dump that means that wh
37 matches
Mail list logo
