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: Pavel Stehule <pavel.stehule@gmail.com>
Cc: jian he <jian.universality@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-13T17:13:51Z
Lists: pgsql-hackers 
Pavel Stehule <pavel.stehule@gmail.com> writes:
> so 12. 10. 2024 v 9:33 odesílatel jian he <jian.universality@gmail.com>
> napsal:
>> + /*
>> + * If we have a location (which, as said above, we really always should)
>> + * then report a line number to aid in localizing problems in big scripts.
>> + */
>> + if (location >= 0)
>> so this part will always be true?

> yes, after  CleanQuerytext the location should not be -1 ever

Right, but we might not have entered either of those previous
if-blocks.  The question here is whether the raw parser (gram.y)
ever throws an error that doesn't include a cursor position.  IMO it
shouldn't, but a quick look through gram.y finds a few ereports that
lack parser_errposition.  We could go fix those, and probably should,
but imagining that none will ever be introduced again seems like
folly.

			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.