Incorrect line and column numbers when a query is missing a semicolon

If you forget to end a query with a semicolon you get:

-- Example queries for sqlc
CREATE TABLE authors (
  id   BIGSERIAL PRIMARY KEY,
  name text      NOT NULL,
  bio  text
);

-- name: GetAuthor :one
SELECT * FROM authors
WHERE id = $1 LIMIT 1;

-- name: ListAuthors :many
SELECT * FROM authors
ORDER BY name

-- name: CreateAuthor :one
INSERT INTO authors (
  name, bio
) VALUES (
  $1, $2
)
RETURNING *;

-- name: DeleteAuthor :exec
DELETE FROM authors
WHERE id = $1;

# package querytest
query.sql:1:1: syntax error at or near "INSERT"

Which is confusing because I start looking at the next query instead of the one above it, and the 1:1 makes me think it's at the beginning of the file which it's not.

Maybe just append this error message with "add a semicolon"?

@kevinburkemeter For which database engine?

Ah, Postgres

We can't provide this information right now due to the lack of structured error messages being returned from pg_query_go pganalyze/pg_query_go#24

@kyleconroy

yes please! it is very confusing. I would probably never realize what is the root cause of the error if I would not find this issue on GitHub...

So @kyleconroy would be really good if you would still find some way to add the structured error messages

Thanks in advance!

@kyleconroy

pg_query_go was moved. here is the correct link: pganalyze/pg_query_go#24

I looked at this, @kyleconroy - is there any reason we can't track the line number of the source file? In the postgresql Parse() function, when p.Parse() returns err, couldn't that be emitted and/or returned with the line of source file?

I am looking here: https://github.com/kyleconroy/sqlc/blob/e2c60566caec2ce7276824e46da792cd98fa05c3/internal/engine/postgresql/parse.go#L165

is there any reason we can't track the line number of the source file?

Yes. The error returned from pg_query.Parse does not include a line number nor location. Parse is called once on the contents of a file. This won't be fixed until pg_query_go returns error with this information.

@kyleconroy

@kyleconroy This actually changed recently (Mar 10) in pganalyze/pg_query_go#76 which has not been released yet (as of May 19, 2023)
( see here )

So the parser.Error type returned should be fully populated (even if the .Error() method still returns just the message):

type Error struct {
	Message   string // exception message
	Funcname  string // source function of exception (e.g. SearchSysCache)
	Filename  string // source of exception (e.g. parse.l)
	Lineno    int    // source of exception (e.g. 104)
	Cursorpos int    // char in query at which exception occurred
	Context   string // additional context (optional, can be NULL)
}

I'm not sure if you want to wait for the next pganalyze/pg_query_go release (v4.2.0 does not contain this change)

Update: pg_query_go has released this functionality in v4.2.1 and #2288 updates sqlc to use this version

Resolved as of v1.19.0.

Navigation Menu

Repository navigation

Incorrect line and column numbers when a query is missing a semicolon #263

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Incorrect line and column numbers when a query is missing a semicolon #263

Description

Activity

cmoog commented on Jan 12, 2020

kevinburke1 commented on Jan 12, 2020

kyleconroy commented on Feb 10, 2020

dskarataev commented on Sep 16, 2020

videate-karim commented on Apr 17, 2021

kyleconroy commented on Aug 28, 2021

StevenACoffman commented on May 19, 2023

StevenACoffman commented on May 28, 2023

andrewmbenton commented on Aug 30, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions