| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Subject: | Re: Statistics Import and Export |
| Date: | 2024-04-03 17:18:07 |
| Message-ID: | 149855.1712164687@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Corey Huinker <corey(dot)huinker(at)gmail(dot)com> writes:
> - functions strive to not ERROR unless absolutely necessary. The biggest
> exposure is the call to array_in().
As far as that goes, it shouldn't be that hard to deal with, at least
not for "soft" errors which hopefully cover most input-function
failures these days. You should be invoking array_in via
InputFunctionCallSafe and passing a suitably-set-up ErrorSaveContext.
(Look at pg_input_error_info() for useful precedent.)
There might be something to be said for handling all the error
cases via an ErrorSaveContext and use of ereturn() instead of
ereport(). Not sure if it's worth the trouble or not.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2024-04-03 17:25:36 | Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? |
| Previous Message | Heikki Linnakangas | 2024-04-03 17:17:31 | Re: Use streaming read API in ANALYZE |