Re: Add expressions to pg_restore_extended_stats()
| От | Michael Paquier |
|---|---|
| Тема | Re: Add expressions to pg_restore_extended_stats() |
| Дата | |
| Msg-id | aYLfl6yV-EK49lfT@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Add expressions to pg_restore_extended_stats() (Corey Huinker <corey.huinker@gmail.com>) |
| Ответы |
Re: Add expressions to pg_restore_extended_stats()
|
| Список | pgsql-hackers |
On Wed, Feb 04, 2026 at 12:14:06AM -0500, Corey Huinker wrote: > I'll switch to adding the nulls to the array result, and add tests for both > leading and trailing expr missing. OK, fine by me. Thanks. Let's make something happen to finish all that. > Mild change of subject, it seems that we can't get the expression fake > attnum context into the errors we re-throw in statatt_build_stavalues - it > might make sense to to bring a version of that function into > extended_stats_funcs where we can add the extra parameters for context (and > avoid the need for a text datum version of some longish strings that we've > already just converted from converting json-string to c-string. If I did > make a new function, then that'd be 2 statatt_* functions that no longer > need to be visible outside of attribute_stats.c. Thoughts on both making > the new function, and maybe sending a few of these statatts back to > static-land? Hmm. I am not sure, that depends. How much additional information would these extra parameter bring to the errors generated in statatt_build_stavalues(). We could also set an error context callback (ErrorContextCallback) within import_pg_statistic() or in the loop that calls the routine, with some data based on the counter of "numexprs" to provide more context about where an error is happening. I have used that in the past to avoid complicating functions across multiple levels of a stack (for example, see ReindexPartitions() in indexcmds.c with its ReindexErrorInfo). -- Michael
Вложения
В списке pgsql-hackers по дате отправления: