Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sRWwx-00G9Ys-Kr for pgsql-general@arkaria.postgresql.org; Wed, 10 Jul 2024 13:01:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sRWww-004wmN-9W for pgsql-general@arkaria.postgresql.org; Wed, 10 Jul 2024 13:01:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sRWwv-004wmF-TG for pgsql-general@lists.postgresql.org; Wed, 10 Jul 2024 13:01:33 +0000 Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sRWwt-001OHz-Oh for pgsql-general@postgresql.org; Wed, 10 Jul 2024 13:01:33 +0000 Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-2c967e21888so4307182a91.1 for ; Wed, 10 Jul 2024 06:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720616490; x=1721221290; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bUcKa2zzUSyGcMSUjka3EmunIiS/7xlCkt4NNu0eAD8=; b=FGO0LOx7RYH7UMPJyu0eg5lJxCtjzqnNmn48uruA4SksbNRziDhdfhOPXi9wB/OiX8 ACp98H2OwhXEcuMjCj2kCkFeo8BW7RKmiL8+Gh6/9DzE34QfZM0lRO9hUmnKSPfRHXI3 2eBV8SOnv2p/bLa9ghEwDkbrclO84EhdIEoNPB+kcHZKKis9FI024SO5zmbToCG5rztf qFSTfGKAwue1af0QdfrDBIs1VI3qKsbr9zcQcfLmyCRxyTsvAcFaN0d1/tipom55rTP6 q7PV7MZkkvAjuhNJQVcvPGFq65YRxg1tGcFfNrJmM4oCid+ZPFH/SlM5+uK5NFq5AB7l Fgkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720616490; x=1721221290; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bUcKa2zzUSyGcMSUjka3EmunIiS/7xlCkt4NNu0eAD8=; b=ZPbEbiuIjYuAsqHVNuoDaRzXD5l+4ghNZvEF6dAsPyX2yntrPy1ggc7g/9oAlXC29c zGGvMXLgFH+hQipndEu52tDi9pDOflCBGVQtSVIc0u1n1f5KX0mVlukX1GJwfVmEjR4H fbmE5vI6iAbEZJP7t8q13YWlaHoBehePTNYK5IDhsm2Vtf1FliLVfv+dlLP0yyCBBp4j heTIigpBGQkrVrdFhFOmR3mQgGCvQRYV4Cqcq7U16pnBIHkP4/ASmHt/H+tDs1NXI7jH ok7o6eK4bvdZD0IW02OaVePYEWhawZ8rQ/VH3aCu4fmf/Hv1Wv9wUL6pCci3r8rbnhAa m/tA== X-Gm-Message-State: AOJu0YwFDNMTlzlxv7SqJjUGzz5rQ+lPtCfy8iHA8/vX918Yv27xehay ZGFEmoR2db8R03BhpbGIjOkQWGkM5G4Rx7b5wBckJmZxP9Cs0uLNljNTJfFC9CgrfNW5ufdhE5d 9G4YWAbIrCT1xMd1TcMPlHKyxVTQ= X-Google-Smtp-Source: AGHT+IHQvMKOMtcLnCxVTPZATPlv71TboyGuyLmJhk1iYKjVlRsOGQ0tyBIppWtBtXOcxnFwxQEHUE3KeP3Bn1e3NBE= X-Received: by 2002:a17:90a:bd82:b0:2c4:aa78:b48b with SMTP id 98e67ed59e1d1-2ca35d486cbmr4580591a91.38.1720616489399; Wed, 10 Jul 2024 06:01:29 -0700 (PDT) MIME-Version: 1.0 References: <71cf3e97-a0a5-4a94-add8-989cd1e2311d@aklaver.com> In-Reply-To: From: Hans Schou Date: Wed, 10 Jul 2024 15:01:13 +0200 Message-ID: Subject: Re: Finding error in long input file To: Rich Shepard Cc: pgsql-general@postgresql.org Content-Type: multipart/alternative; boundary="000000000000a544d2061ce43e20" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a544d2061ce43e20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If the file has these line breaks you show, then can make it to multiple 'INSERT INTO' instead. Search for lines starting with parentese begin '(' and replace it with the correct INSERT and last comma to semi-colon: cat i.sql | sed -e 's/^(/INSERT INTO foo VALUES(/' -e 's/,$/;/' Does the file come from mysqldump? Then try option --extended-insert=3DFALS= E On Wed, Jul 10, 2024 at 2:53=E2=80=AFPM Rich Shepard wrote: > On Tue, 9 Jul 2024, Craig McIlwee wrote: > > > The input file is 488 lines (presumably, since Rich said the file shoul= d > > 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 = 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, et al., > > I use emacs for scripts and coding, joe's only for small jobs. > > I added a line to the file so the bottom line is now 489. The attached > image > shows that line is the only one terminated with a semicolon rather than a > comma. > > psql would tell me if there was no closing parenthesis on a line, if the > terminating comma was missing, or other similar error, and would tell me > the > number of the line or following line. Having the error marked at the end = of > the file does not tell _me_ just where the error actually is. > > Partial screenshot attached. > > Thanks all, > > Rich --=20 =F0=9D=95=B3=F0=9D=96=86=F0=9D=96=93=F0=9D=96=98 =F0=9D=95=BE=F0=9D=96=88= =F0=9D=96=8D=F0=9D=96=94=F0=9D=96=9A =E2=98=8F =E2=9E=81=E2=9E=81 =E2=9E=85=E2=9E=83 =E2=9E=87=E2=93=AA =E2=9E= =81=E2=93=AA --000000000000a544d2061ce43e20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the file has these line breaks you show, then can = make it to multiple 'INSERT INTO' instead.

Search for lines starting with parentese begin '(' and replace it = with the correct INSERT and last comma to semi-colon:
=C2=A0 cat = i.sql | sed -e 's/^(/INSERT INTO foo VALUES(/' -e 's/,$/;/'=

Does the file come from mysqldump? Then try optio= n --extended-insert=3DFALSE

On Wed, Jul 10, 2024= at 2:53=E2=80=AFPM Rich Shepard <rshepard@appl-ecosys.com> wrote:
On Tue, 9 Jul 2024, Craig McIlwee wrote:

> The input file is 488 lines (presumably, since Rich said the file shou= ld
> insert 488 rows). It seems like too much of a coincidence that the las= t
> character of the last line is really the error. My guess is that there= is
> an unmatched character, perhaps a parenthesis, that is throwing off th= e
> parser because it doesn't expect the statement to terminate yet. M= aybe
> that unmatched char really is on the last line, but '85250 Red Hou= se Rd'
> doesn't seem like the issue. I don't know anything about the j= oe editor,
> but I'd hope that any decent editor with syntax highlighting would= make it
> apparent where things went awry.

Craig, et al.,

I use emacs for scripts and coding, joe's only for small jobs.

I added a line to the file so the bottom line is now 489. The attached imag= e
shows that line is the only one terminated with a semicolon rather than a comma.

psql would tell me if there was no closing parenthesis on a line, if the terminating comma was missing, or other similar error, and would tell me th= e
number of the line or following line. Having the error marked at the end of=
the file does not tell _me_ just where the error actually is.

Partial screenshot attached.

Thanks all,

Rich


--
=F0=9D=95=B3=F0=9D=96=86=F0=9D=96=93=F0= =9D=96=98=C2=A0=F0=9D=95=BE=F0=9D=96=88=F0=9D=96=8D=F0=9D=96=94=F0=9D=96=9A=
=E2=98=8F =E2=9E=81=E2=9E=81 =E2=9E=85=E2=9E=83 =E2=9E=87=E2= =93=AA =E2=9E=81=E2=93=AA
--000000000000a544d2061ce43e20--