"inaccurate" might be an understatement. My query is 9 lines long. When I remove a comma from the select clause in order to generate an error, much of the error content comes back correct, even position which appears to be relatively accurate. On the other hand, I get 1052 as the lune number for the error, which is clearly off. I'm assuming there's an issue in the parseE error parser, but haven't investigated much further yet.
Additional note: this error occurs identically if the query is parameterized as well
upon further inspection, this line number appears to be pointing back to the postgres source code, not the query. It's pointing to a section in the lexer that is throwing the syntax error I'm generating. So I guess I have 2 questions:
It's always been like this, PostgreSQL only reports code lines inside its C++ parser, and it never reports line numbers for the SQL query, it only provides a description.
Most likely you can't get any more details than that.
You're right, it's more clear in the postgres docs.
Given the position value, though, one should be able to determine it, _if_ the "original query string" it refers to in the docs for position is the same whether a query is parameterized or not. In other words, does the parameterization occur before or after the position is determined, and if it's after, then I don't think I could readily determine the line at that point reliably.
Anyone know off hand if the position is determined before or after parameterization? If not, I'll test later and report back.
So good news, the position is calculated _prior_ to interpolating the parameterized query. This means you can essentially calculate the line number like this (I'll leave it to others to optimize):
// assuming `query` is the original query passed to pg, parameterized or otherwise
client.query(query, function(err) {
if (err) {
console.error('line : %s', ((query.substring(0, err.position).match(/\n/g) || []).length + 1));
}
});
I'll close this and leave these comments as a pointer to anyone else wanting to get the query's line number for a given error.
Most helpful comment
So good news, the
positionis calculated _prior_ to interpolating the parameterized query. This means you can essentially calculate the line number like this (I'll leave it to others to optimize):I'll close this and leave these comments as a pointer to anyone else wanting to get the query's line number for a given error.