Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)
Date
Msg-id 3482022.1728839631@sss.pgh.pa.us
Whole thread Raw
In response to Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)
Next
From: Tom Lane
Date:
Subject: Re: general purpose array_sort