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

[kevinburke1]

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"?

[cmoog]

@kevinburkemeter For which database engine?

[kevinburke1]

Ah, Postgres

[kyleconroy]

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

[dskarataev]

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!

[videate-karim]

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

[kyleconroy]

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.

[StevenACoffman]

@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)