Greg Stark wrote:
> Bruce Momjian writes:
>
> > Zeugswetter Andreas DCP SD wrote:
> >
> > > I thought the suggested procedure (see migration doc) was to use the
> > > new pg_dump to dump the older db version, so why backpatch ?
> >
> > Uh, you can suggest it, but I would guess < 50% do it, and
Bruce Momjian writes:
> Zeugswetter Andreas DCP SD wrote:
>
> > I thought the suggested procedure (see migration doc) was to use the
> > new pg_dump to dump the older db version, so why backpatch ?
>
> Uh, you can suggest it, but I would guess < 50% do it, and once the old
> database is gone, t
Tom Lane wrote:
> Bruce Momjian writes:
> > Very clear. The issue is that I can't find any of these emitted by a
> > pg_dump version who's native backend doesn't understand them.
>
> So? We're not doing anything differently in that regard either. 8.2
> will understand the SET, what's the probl
> > I thought the suggested procedure (see migration doc) was to use the
> > new pg_dump to dump the older db version, so why backpatch ?
>
> Uh, you can suggest it, but I would guess < 50% do it, and once the
old
> database is gone, there is no way to re-do the dump.
But you can still load the
Bruce Momjian writes:
> Very clear. The issue is that I can't find any of these emitted by a
> pg_dump version who's native backend doesn't understand them.
So? We're not doing anything differently in that regard either. 8.2
will understand the SET, what's the problem?
Zeugswetter Andreas DCP SD wrote:
>
> > Very clear. The issue is that I can't find any of these emitted by a
> > pg_dump version who's native backend doesn't understand them.
> >
> > I assume that it is expected that a cross-db dump/reload will generate
> > errors, and it is done rarely for upgr
> Very clear. The issue is that I can't find any of these emitted by a
> pg_dump version who's native backend doesn't understand them.
>
> I assume that it is expected that a cross-db dump/reload will generate
> errors, and it is done rarely for upgrades, but I assume same-version
> dump/restore
Tom Lane wrote:
> Bruce Momjian writes:
> > You mean dumping and reloading pg_dump output in 7.3 generates errors?
> > I didn't know. Can you give an example? I wasn't aware of that.
>
> Well, looking at the SETs already currently emitted:
>
> $ pg_dump -s regression | grep ^SET
> SET client_
Bruce Momjian writes:
> You mean dumping and reloading pg_dump output in 7.3 generates errors?
> I didn't know. Can you give an example? I wasn't aware of that.
Well, looking at the SETs already currently emitted:
$ pg_dump -s regression | grep ^SET
SET client_encoding = 'SQL_ASCII'; fai
Tom Lane wrote:
> Bruce Momjian writes:
> > The basic issue is that we need to set standard_conforming_strings to
> > 'off' for loading into newer releases, >= 8.2, but that SET command is
> > going to generate an error even dumping/loading into the same version of
> > PostgreSQL, like 7.3 to 7.3.
Bruce Momjian writes:
> The basic issue is that we need to set standard_conforming_strings to
> 'off' for loading into newer releases, >= 8.2, but that SET command is
> going to generate an error even dumping/loading into the same version of
> PostgreSQL, like 7.3 to 7.3. I don't think we want th
The basic issue is that we need to set standard_conforming_strings to
'off' for loading into newer releases, >= 8.2, but that SET command is
going to generate an error even dumping/loading into the same version of
PostgreSQL, like 7.3 to 7.3. I don't think we want that, do we? I agree
we can have
Tom Lane wrote:
> Bruce Momjian writes:
> > I have seen no reply to my suggestion below, so I assume it is the way
> > people want to go for 7.3, 7.4, and 8.0.
>
> I'm not particularly for it, if that's what you meant, and certainly not
> for hacking up old branches that way. For one thing, you
Bruce Momjian writes:
> I have seen no reply to my suggestion below, so I assume it is the way
> people want to go for 7.3, 7.4, and 8.0.
I'm not particularly for it, if that's what you meant, and certainly not
for hacking up old branches that way. For one thing, you can't
retroactively cause se
I have seen no reply to my suggestion below, so I assume it is the way
people want to go for 7.3, 7.4, and 8.0.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > -- Set escape environment for poss
Tom Lane wrote:
> Bruce Momjian writes:
> > -- Set escape environment for possible loading into version >= 8.2.
> > -- If variables are not supported, suppress error messages.
> > SET client_min_messages = panic;
> > SET log_min_messages = log;
> > SET log_min_error_statement =
Bruce Momjian writes:
> -- Set escape environment for possible loading into version >= 8.2.
> -- If variables are not supported, suppress error messages.
> SET client_min_messages = panic;
> SET log_min_messages = log;
> SET log_min_error_statement = panic;
> SE
pg_dump is designed to produce dumps that can be loaded into newer
PostgreSQL versions, and it can read from older database versions.
The new backslash escape warning and sql standard strings might cause
problems for people moving from older versions of PostgreSQL, because
pg_dump assumes identifi
18 matches
Mail list logo
