Horton

Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: jian he <jian.universality@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Christoph Berg <myon@debian.org>, Michael Banck <mbanck@gmx.net>, Tommy Pavlicek <tommypav122@gmail.com>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, pgsql-hackers@lists.postgresql.org
Date: 2024-10-16T18:17:58Z
Lists: pgsql-hackers 
jian he <jian.universality@gmail.com> writes:
> just found out the"elog(INFO, "should not reached here");" part never reached.

You didn't check any of the cases we were discussing I guess?
(That is, places in gram.y that throw an error without a
parser_errposition call.)

Note that even if we fix all of those and keep them fixed, we still
couldn't assume the case is unreachable, because gram.y isn't
self-contained.  For instance, if we hit out-of-memory during raw
parsing, the OOM error out of mcxt.c isn't going to provide a syntax
error position.  I'm not too concerned about doing better than what
the patch does now (i.e. nothing) in such edge cases, but we can't
do worse.

> i guess, we don't need performance in script_error_callback,
> but in script_error_callback arrange code seperate  syntax error(raw
> parser) and other error seems good.
> please check the attached minor refactor.

I do not think that's an improvement.  It's more complicated and
less readable, and I don't see why we need to squeeze more
performance out of this error-reporting path that should never
be taken in production.

			regards, tom lane

Commits

  1. Strip Windows newlines from extension script files manually.

  2. Read extension script files in text not binary mode.

  3. Improve reporting of errors in extension script files.

  4. Improve parser's reporting of statement start locations.

  5. Extend ALTER OPERATOR to allow setting more optimization attributes.

  6. Core support for "extensions", which are packages of SQL objects.