Re: Statistics Import and Export
| От | Corey Huinker |
|---|---|
| Тема | Re: Statistics Import and Export |
| Дата | |
| Msg-id | CADkLM=egYXeOGF2=AxOYej-=VjTNb3wcyEPqKd7_0CLxfKppjw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Statistics Import and Export (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Statistics Import and Export
|
| Список | pgsql-hackers |
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.)
Ah, my understanding may be out of date. I was under the impression that that mechanism relied on the the cooperation of the per-element input function, so even if we got all the builtin datatypes to play nice with *Safe(), we were always going to be at risk with a user-defined input function.
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.
It would help us tailor the user experience. Right now we have several endgames. To recap:
1. NULL input => Return NULL. (because strict).
2. Actual error (permissions, cache lookup not found, etc) => Raise ERROR (thus ruining binary upgrade)
3. Call values are so bad (examples: attname not found, required stat missing) that nothing can recover => WARN, return FALSE.
4. At least one stakind-stat is wonky (impossible for datatype, missing stat pair, wrong type on input parameter), but that's the worst of it => 1 to N WARNs, write stats that do make sense, return TRUE.
5. Hunky-dory. => No warns. Write all stats. return TRUE.
Which of those seem like good ereturn candidates to you?
В списке pgsql-hackers по дате отправления: