Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> Maybe instead we can change the COPY command to read the file directly and
> >> not via stdin? Then we don't need the \. marker.
>
> I like that idea too.
>
> > Yes, we need a temp table then. The singl
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Jon Jensen writes:
>> I hate to mention it, but would it be useful/non-overkill to make either
>> of those things (context message maximum length and funny character
>> escaping) configurable somehow?
> I'm thinking the same. We have conflicting need
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> Maybe instead we can change the COPY command to read the file directly and
>> not via stdin? Then we don't need the \. marker.
I like that idea too.
> Yes, we need a temp table then. The single-line fix seemed easier.
Why a
On Sat, Sep 27, 2003 at 01:08:37PM -0400, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > That is all besides the point. If adding -f to the command line is for
> > some reason prohibitive, then the same applies to -e. That is all.
>
> Seems we should recommend -f rather than "<" for restore
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > OK, I have applied a patch to make initdb create a COPY file with
> > consistent end-of-line termination, so it passes the COPY EOL checking.
>
> Maybe instead we can change the COPY command to read the file directly and
> not via stdin? Then
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > You are assuming it is easy to find what is on a specific line of the
> > dump file. I am not sure that is always easy for people with limited
> > Unix skills, or MSWin folks. I am not sure I would have thought to add
> > the file offset to f
Bruce Momjian writes:
> OK, I have applied a patch to make initdb create a COPY file with
> consistent end-of-line termination, so it passes the COPY EOL checking.
Maybe instead we can change the COPY command to read the file directly and
not via stdin? Then we don't need the \. marker.
--
Pet
Bruce Momjian writes:
> You are assuming it is easy to find what is on a specific line of the
> dump file. I am not sure that is always easy for people with limited
> Unix skills, or MSWin folks. I am not sure I would have thought to add
> the file offset to find the problem COPY line. I guess
Peter Eisentraut wrote:
> Oliver Elphick writes:
>
> > +
> > + With a large dump, it may be difficult to identify where any errors are
> > + occurring. You may use the -e option to psql to print the SQL commands
> > + as they are run, so that it is easy to see precisely which comm
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Tom Lane writes:
> >
> > > so it appears that cygwin's "echo" generates a different newline style
> > > than what got put into sql_features.txt. A possible way to fix this is
> > > to put the "\." line into sql_features.txt, but maybe there's a c
Oliver Elphick writes:
> +
> + With a large dump, it may be difficult to identify where any errors are
> + occurring. You may use the -e option to psql to print the SQL commands
> + as they are run, so that it is easy to see precisely which commands are
> + causing errors.
>
Jon Jensen writes:
> I hate to mention it, but would it be useful/non-overkill to make either
> of those things (context message maximum length and funny character
> escaping) configurable somehow?
I'm thinking the same. We have conflicting needs of different groups:
Users on "real" Unix platfor
On Fri, 2003-09-26 at 23:18, Bruce Momjian wrote:
> If you are loading from pg_dump, you have lots of copy commands, so how
> do you know which COPY command caused the failure. You just have the
> line number of _a_ copy.
I would recommend using
psql -e
so that the sql commands are output too.
Jon Jensen wrote:
> On Fri, 26 Sep 2003, Tom Lane wrote:
>
> > I was chewing this over with Bruce on the phone just now, and we refined
> > the idea a little. Some errors (primarily those detected inside the
> > datatype input procedures) can be clearly traced to a specific column,
> > whereas ot
On Fri, 26 Sep 2003, Tom Lane wrote:
> I was chewing this over with Bruce on the phone just now, and we refined
> the idea a little. Some errors (primarily those detected inside the
> datatype input procedures) can be clearly traced to a specific column,
> whereas others (such as too many fields
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > so it appears that cygwin's "echo" generates a different newline style
> > than what got put into sql_features.txt. A possible way to fix this is
> > to put the "\." line into sql_features.txt, but maybe there's a cleaner
> > answer. Peter, any th
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Minimalism isn't really a virtue in error reports anyway.
>> I'm thinking maybe:
>> CONTEXT: COPY tablename, line 41: "data ..."
>> would serve the purpose nicely.
> The only thing that would really help in the general case is the number of
> the ch
Peter Eisentraut wrote:
> scott.marlowe writes:
>
> > table name too, like Bruce said. The bothersome bit is that in pg_dump,
> > it says the line, relative to just this part of the copy command, so you
> > don't even know which table is giving the error.
>
> I don't see the problem. Can't you
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > The argument that you want a warning because you might have mixed
> > newlines in the file seems less likely than this case where they are
> > using a literal carriage return as a data value at the end of the line.
>
> I don't agree with that
Tom Lane writes:
> This doesn't seem like a good argument not to add more information to
> the CONTEXT line for COPY errors. Sure, in theory the existing info
> should be sufficient, but what if the information is not coming in
> through psql? (For instance, maybe the COPY data is being generate
I said:
> The question isn't so much "who has CRs in their data" as "who is trying
> to import data files in which CRs aren't correctly represented as \r" ?
> Not anyone upgrading from a recent PG release ... though 7.1 or before
> would have an issue.
Actually, checking the CVS logs shows that 7.
scott.marlowe writes:
> psql:webport.sql:803: ERROR: function "odbc_user" already exists with
> same argument types
> REVOKE
> REVOKE
> GRANT
> You are now connected as new user "ayousuff".
> psql:webport.sql:869: ERROR: literal newline found in data
> HINT: Use "\n" to represent newline.
> CON
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> The argument that you want a warning because you might have mixed
>> newlines in the file seems less likely than this case where they are
>> using a literal carriage return as a data value at the end of the line.
> I don't agr
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
> scott.marlowe writes:
>
> > table name too, like Bruce said. The bothersome bit is that in pg_dump,
> > it says the line, relative to just this part of the copy command, so you
> > don't even know which table is giving the error.
>
> I don't see th
On Fri, 26 Sep 2003, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > scott.marlowe writes:
> >> but I get basically the same thing if I dump it to a .sql file and do:
> >> psql dbname
> > Use psql -f dbname.sql instead.
>
> This doesn't seem like a good argument not to add mo
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
> scott.marlowe writes:
>
> > but I get basically the same thing if I dump it to a .sql file and do:
> >
> > psql dbname
> Use psql -f dbname.sql instead.
and the output is:
psql:webport.sql:803: ERROR: function "odbc_user" already exists with
sa
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> scott.marlowe writes:
>> but I get basically the same thing if I dump it to a .sql file and do:
>> psql dbname Use psql -f dbname.sql instead.
This doesn't seem like a good argument not to add more information to
the CONTEXT line for COPY errors. Su
--On Friday, September 26, 2003 14:36:08 -0600 "scott.marlowe"
<[EMAIL PROTECTED]> wrote:
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
Bruce Momjian writes:
> The argument that you want a warning because you might have mixed
> newlines in the file seems less likely than this case where they a
scott.marlowe writes:
> but I get basically the same thing if I dump it to a .sql file and do:
>
> psql dbname
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > The argument that you want a warning because you might have mixed
> > newlines in the file seems less likely than this case where they are
> > using a literal carriage return as a data value at the end of the line.
>
> I
Bruce Momjian writes:
> The argument that you want a warning because you might have mixed
> newlines in the file seems less likely than this case where they are
> using a literal carriage return as a data value at the end of the line.
I don't agree with that assessment. Who actually has CRs in t
scott.marlowe writes:
> table name too, like Bruce said. The bothersome bit is that in pg_dump,
> it says the line, relative to just this part of the copy command, so you
> don't even know which table is giving the error.
I don't see the problem. Can't you identify the failing command by the
li
On Fri, 26 Sep 2003, Bruce Momjian wrote:
> scott.marlowe wrote:
> > > OK, 'vi' shows it as:
> > >
> > > COPY people2 (id, persons) FROM stdin;
> > > 59 Chance Terry--S
> > > 60 ^M
> > > \.
> > >
> > > which is _exactly the case the error was supposed to catch. Now, the
> >
On Fri, 26 Sep 2003, Bruce Momjian wrote:
> scott.marlowe wrote:
> > > OK, 'vi' shows it as:
> > >
> > > COPY people2 (id, persons) FROM stdin;
> > > 59 Chance Terry--S
> > > 60 ^M
> > > \.
> > >
> > > which is _exactly the case the error was supposed to catch. Now, the
> >
On Fri, Sep 26, 2003 at 03:05:58PM -0400, Tom Lane wrote:
> Not sure if we should make the behavior Windows-specific though. And
> didn't Michael report seeing the same initdb failure on Debian? That
> confuses me a bit --- why would there be a newline discrepancy on Debian?
I take it there are
scott.marlowe wrote:
> > OK, 'vi' shows it as:
> >
> > COPY people2 (id, persons) FROM stdin;
> > 59 Chance Terry--S
> > 60 ^M
> > \.
> >
> > which is _exactly the case the error was supposed to catch. Now, the
> > big question is where did this dump come from? Pg
On Fri, 26 Sep 2003, Bruce Momjian wrote:
> scott.marlowe wrote:
> > The attached file produces this problem. Note it's a blank trailing field
> > that looks to be causing it. The error for this .sql file is:
> >
> > ERROR: literal carriage return found in data
> > HINT: Use "\r" to represen
Bruce Momjian wrote:
> scott.marlowe wrote:
> > The attached file produces this problem. Note it's a blank trailing field
> > that looks to be causing it. The error for this .sql file is:
> >
> > ERROR: literal carriage return found in data
> > HINT: Use "\r" to represent carriage return.
> >
scott.marlowe wrote:
> The attached file produces this problem. Note it's a blank trailing field
> that looks to be causing it. The error for this .sql file is:
>
> ERROR: literal carriage return found in data
> HINT: Use "\r" to represent carriage return.
> CONTEXT: COPY FROM, line 2
>
> N
On Fri, 26 Sep 2003, Tom Lane wrote:
> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > I'm running into issues where 7.4's pg_dump/pg_dumpall from a 7.2 database
> > to a 7.4beta3 database is producing some errors like this:
>
> > ERROR: literal newline found in data
> > HINT: Use "\n" to repr
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Yeah, I was wondering whether you wouldn't propose dropping the newline
>> consistency check. I'm not very comfortable with that, but maybe we
>> should. Bruce?
> I don't mind if we keep it on pure-POSIX platforms. But one of th
Tom Lane wrote:
> > ERROR: literal carriage return found in data
> > HINT: Use "\r" to represent carriage return.
> > CONTEXT: COPY FROM, line 41
>
> Really? 7.2 should dump data \r or \n as the backslash versions ...
> and does in my tests. Can you make a reproducible test case?
>
>
>
> >
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> I'm running into issues where 7.4's pg_dump/pg_dumpall from a 7.2 database
> to a 7.4beta3 database is producing some errors like this:
> ERROR: literal newline found in data
> HINT: Use "\n" to represent newline.
> CONTEXT: COPY FROM, line 59
> E
On Fri, 26 Sep 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > Tom Lane writes:
> > >> so it appears that cygwin's "echo" generates a different newline style
> > >> than what got put into sql_features.txt. A possible way to fix this is
> > >> to
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > ... we could add code to throw the WARNING
> > only once per COPY command --- that would probably make sense.
>
> Seems like a bit of a kluge, but perhaps the best compromise. It would
> be quite likely that you'd get the same warnin
Tom Lane writes:
> Yeah, I was wondering whether you wouldn't propose dropping the newline
> consistency check. I'm not very comfortable with that, but maybe we
> should. Bruce?
I don't mind if we keep it on pure-POSIX platforms. But one of the nicer
developments on Windows in recent(?) times
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ... we could add code to throw the WARNING
> only once per COPY command --- that would probably make sense.
Seems like a bit of a kluge, but perhaps the best compromise. It would
be quite likely that you'd get the same warning on many lines of a COPY,
a
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > so it appears that cygwin's "echo" generates a different newline style
> > than what got put into sql_features.txt. A possible way to fix this is
> > to put the "\." line into sql_features.txt, but maybe there's a cleaner
> > answer. Peter, any th
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Perhaps we can throw a warning rather than an error, and adjust initdb
> > to be consistent.
>
> I like the idea of reducing the newline consistency check to a warning.
> There is one thing we'd have to watch for though (it's already
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >I posted on that a few minutes ago. Yea, we can drop it, but we risk
> >eating carraige returns as data values. I am not sure how consistently
> >we output literal carriage returns in old dumps, nor how many apps
> >produce on literal carriage re
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Perhaps we can throw a warning rather than an error, and adjust initdb
> to be consistent.
I like the idea of reducing the newline consistency check to a warning.
There is one thing we'd have to watch for though (it's already an issue
but would become a
Bruce Momjian wrote:
I posted on that a few minutes ago. Yea, we can drop it, but we risk
eating carraige returns as data values. I am not sure how consistently
we output literal carriage returns in old dumps, nor how many apps
produce on literal carriage returns in COPY. If we conditionally eat
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> so it appears that cygwin's "echo" generates a different newline style
> >> than what got put into sql_features.txt. A possible way to fix this is
> >> to put the "\." line into sql_features.txt, but maybe the
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> so it appears that cygwin's "echo" generates a different newline style
>> than what got put into sql_features.txt. A possible way to fix this is
>> to put the "\." line into sql_features.txt, but maybe there's a cleaner
>> answer.
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > so it appears that cygwin's "echo" generates a different newline style
> > than what got put into sql_features.txt. A possible way to fix this is
> > to put the "\." line into sql_features.txt, but maybe there's a cleaner
> > answer. Peter, any th
Tom Lane writes:
> so it appears that cygwin's "echo" generates a different newline style
> than what got put into sql_features.txt. A possible way to fix this is
> to put the "\." line into sql_features.txt, but maybe there's a cleaner
> answer. Peter, any thoughts?
There's no clean answer to
On Fri, Sep 26, 2003 at 11:01:34AM -0400, Tom Lane wrote:
> > I am getting the error:
> > "
> > creating information schema... ERROR: end-of-copy marker does not match
> > previous newline style
> > CONTEXT: COPY FROM, line 361
> > "
>
> That's interesting. COPY is complaining because the \. t
On Fri, 2003-09-26 at 11:01, Tom Lane wrote:
> so it appears that cygwin's "echo" generates a different newline style
> than what got put into sql_features.txt. A possible way to fix this is
> to put the "\." line into sql_features.txt, but maybe there's a cleaner
> answer. Peter, any thoughts?
Tim McAuley <[EMAIL PROTECTED]> writes:
> Another question now. I am unable to compile Postgresql 7.4 beta 3 under
> cygwin (Windows 2K, using cgyipc 2).
> I am getting the error:
> "
> creating information schema... ERROR: end-of-copy marker does not match
> previous newline style
> CONTEXT:
59 matches
Mail list logo
