Re: pltcl crashes due to a syntax error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Erik Wienhold <ewie(at)ewie(dot)name>
Cc: Pierre Forstmann <pierre(dot)forstmann(at)gmail(dot)com>, "a(dot)kozhemyakin" <a(dot)kozhemyakin(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pltcl crashes due to a syntax error
Date: 2024-06-02 22:15:48
Message-ID: 2365308.1717366548@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Erik Wienhold <ewie(at)ewie(dot)name> writes:
> Tcl_GetVar returns null if errorInfo does not exist. Omitting econtext
> from errcontext in that case looks like the proper fix to me.

Yeah, that was the conclusion I came to last night while sitting in
the airport, but I didn't have time to prepare a cleaned-up patch.

The new bit of information that this bug report provides is that it's
possible to get a TCL_ERROR result without Tcl having set errorInfo.
That seems a tad odd, and it must happen only in weird corner cases,
else we'd have heard of this decades ago. Not sure if it's worth
trying to characterize those cases further, however.

> Or just do away with throw_tcl_error and call ereport directly.

I'd say this adds to the importance of having throw_tcl_error,
because now it's even more complex than before, and there are
multiple call sites.

> Compare
> that to pltcl_trigger_handler where the same case is handled like this:

Hm, I wonder why that's not using throw_tcl_error. I guess because
it wants to give its own primary message, but still ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joseph Koshakow 2024-06-02 23:01:15 Re: Fix overflow hazard in interval rounding
Previous Message Peter Eisentraut 2024-06-02 21:31:03 Re: Schema variables - new implementation for Postgres 15