From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Craig McIlwee <craigm(at)vt(dot)edu> |
Cc: | Rich Shepard <rshepard(at)appl-ecosys(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Finding error in long input file |
Date: | 2024-07-10 04:58:07 |
Message-ID: | 155fc2ec-d936-4838-b4dd-ca7d06acb6a1@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 7/9/24 17:46, Craig McIlwee wrote:
> Full error message from earlier in the thread:
>
> > psql:scripts/insert-addrs.sql:488: ERROR: syntax error at or near ";"
> > LINE 488: ...2832,1,default,'85250 Red House Rd','Paisley','OR','97636');
> >
> ^
>
>
> The error:
>
> LINE 488: ...2832,1,default,'85250 Red House Rd','Paisley','OR','97636')
>
> is giving you the line number and the data:
> a) Navigate to that line number using whatever method Joe has for that.
> b) Search for '85250 Red House Rd'.
>
>
>
> The input file is 488 lines (presumably, since Rich said the file should
> insert 488 rows). It seems like too much of a coincidence that the last
> character of the last line is really the error. My guess is that there
This assumes that there where only INSERT lines and that each INSERT was
only one line. I have bit by those assumptions before, hence my
suggestion to actually find line 488.
> is an unmatched character, perhaps a parenthesis, that is throwing off
> the parser because it doesn't expect the statement to terminate yet.
> Maybe that unmatched char really is on the last line, but '85250 Red
> House Rd' doesn't seem like the issue. I don't know anything about the
> joe editor, but I'd hope that any decent editor with syntax highlighting
> would make it apparent where things went awry.
>
> Craig
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Alban Hertroys | 2024-07-10 06:57:52 | Re: Finding error in long input file |
Previous Message | Guyren Howe | 2024-07-10 02:38:37 | Re: can stored procedures with computational sql queries improve API performance? |