My tests suggest that a feature of pg_restore is that it is only
expected to work with its own server. Indeed, it generates some new
syntax, such as $$ quoting, which is not compatible with older servers.
This fact does not seem to appear in the documentation.
Wrong. It does appear in
please find a small patch submission so that pg_restore ignores some sql
errors.
Yeah, we've been talking about doing that for awhile. But please define
some errors --- what do you ignore exactly?
Connection errors are not ignored.
The error is triggered directly by the execute sql
Fabien COELHO said:
Well, it means that you must decide a dump time if you may have to
restore in an older version. I can guess why it eased the
implementation, but it does not look good.
You want to be able to backup from version x to version y for some yx? We
support upgrades, not
Dear Andrew,
Well, it means that you must decide a dump time if you may have to
restore in an older version. I can guess why it eased the
implementation, but it does not look good.
You want to be able to backup from version x to version y for some yx? We
support upgrades, not
Dear patchers,
please find attached a small patch so that pg_restore ignores some sql
errors. This is the second submission, which integrates Tom comments about
localisation and exit code. I also added some comments about one sql
command which is not ignored.
I tested it.
Have a nice day,
--
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
What is command output and how does that differ from stdout?
In this case, stdout is going to psql's stdout, not to the command
stdout.
Hm, I didn't realize it worked like that. So command output means
where
Patch applied. Thanks.
---
Fabien COELHO wrote:
Dear patchers,
Please find a small patch to fix the brain damage century and
millennium date part implementation in postgresql, both in the code and
the
I have reviewed this patch. Basically, CSV is enabled by specifying
more than one delimiter character to COPY, e.g. DELIMITER ',' or
DELIMITER ','. Is this API good for folks?
Prior to 7.2, a multi-character delimiter could be specified, but only
the first character was used. 7.2 release
Bruce Momjian wrote:
I have reviewed this patch. Basically, CSV is enabled by specifying
more than one delimiter character to COPY, e.g. DELIMITER ',' or
DELIMITER ','. Is this API good for folks?
(if not I'll be displeased, as it is what was the general consensus
about a month ago)
Prior
I have applied the attached patch:
Exit backend from SIGTERM or FATAL by simulating client EOF, rather than
calling proc_exit() directly. This should make SIGTERM more reliable.
---
Tom Lane wrote:
Bruce Momjian
Andrew Dunstan wrote:
Bruce Momjian wrote:
I have reviewed this patch. Basically, CSV is enabled by specifying
more than one delimiter character to COPY, e.g. DELIMITER ',' or
DELIMITER ','. Is this API good for folks?
(if not I'll be displeased, as it is what was the general
Bruce Momjian wrote:
Prior to 7.2, a multi-character delimiter could be specified, but only
the first character was used. 7.2 release notes state:
* COPY DELIMITERS string must be exactly one character (Tom)
I am a little worried about multibyte too, as you mentioned.
I am not
Andrew Dunstan wrote:
I am not sure that CSVs even make sense in a multibyte world. If not, it
would make sense to disable it in such a case.
(Is that your only worry?)
Yes, my worry is that someone will use a multibyte character that the
system sees as several bytes and enters
13 matches
Mail list logo
