Applied.
---
Bruce Momjian wrote:
Peter Eisentraut wrote:
Tom Lane wrote:
Is this acceptable to everyone? We could name the option
-u/--upgrade-compatible.
If the switch is specifically for pg_upgrade
Peter Eisentraut wrote:
Tom Lane wrote:
Is this acceptable to everyone? We could name the option
-u/--upgrade-compatible.
If the switch is specifically for pg_upgrade support (enabling this as
well as any other hacks we find necessary), which seems like a good
idea, then don't chew
Tom Lane wrote:
Is this acceptable to everyone? We could name the option
-u/--upgrade-compatible.
If the switch is specifically for pg_upgrade support (enabling this as
well as any other hacks we find necessary), which seems like a good
idea, then don't chew up a short option letter for it.
bruce wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
Now that pg_migrator is BSD licensed, and already in C, I am going to
spend my time trying to improve pg_migrator for 8.4:
http://pgfoundry.org/projects/pg-migrator/
What is the plan now? Get pg_upgrade working, get
Bruce Momjian br...@momjian.us writes:
I can think of three possible solutions, all involve recreating and
dropping the dropped column in the new schema:
(4) add a switch to pg_dump to include dropped columns in its
schema output and then drop them. This seems far more maintainable
than
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I can think of three possible solutions, all involve recreating and
dropping the dropped column in the new schema:
(4) add a switch to pg_dump to include dropped columns in its
schema output and then drop them. This seems far more
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
(4) add a switch to pg_dump to include dropped columns in its
schema output and then drop them. This seems far more maintainable
than writing separate code that tries to parse the output.
I assume I would also drop the column in the
On Thu, 2009-02-12 at 13:39 -0500, Tom Lane wrote:
Right, that's what I meant --- do all the work within pg_dump.
Is this acceptable to everyone? We could name the option
-u/--upgrade-compatible.
If the switch is specifically for pg_upgrade support (enabling this as
well as any other
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
(4) add a switch to pg_dump to include dropped columns in its
schema output and then drop them. This seems far more maintainable
than writing separate code that tries to parse the output.
I assume I would also
Joshua D. Drake wrote:
On Thu, 2009-02-12 at 13:39 -0500, Tom Lane wrote:
Right, that's what I meant --- do all the work within pg_dump.
Is this acceptable to everyone? We could name the option
-u/--upgrade-compatible.
If the switch is specifically for pg_upgrade support
Joshua D. Drake j...@commandprompt.com writes:
On Thu, 2009-02-12 at 13:39 -0500, Tom Lane wrote:
a long form only. And probably not even list it in the user
documentation.
Why wouldn't we want to list it?
Because it's for internal use only. Although the effect we're
discussing here is
Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
On Thu, 2009-02-12 at 13:39 -0500, Tom Lane wrote:
a long form only. And probably not even list it in the user
documentation.
Why wouldn't we want to list it?
Because it's for internal use only. Although the effect
12 matches
Mail list logo
