Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp
| От | Amul Sul |
|---|---|
| Тема | Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp |
| Дата | |
| Msg-id | CAAJ_b95q2VOGz_Lq-6NnFqF60swQXeWtJe+UWeUUCu+yEWawgQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp (Michael Paquier <michael@paquier.xyz>) |
| Список | pgsql-hackers |
On Wed, Nov 26, 2025 at 5:13 PM Michael Paquier <michael@paquier.xyz> wrote: > > > Hmm. Following the previous example you have quoted, I am wondering > if we'd tweak the names a bit differently. Rather than the > popo_overflow_safe() pattern from your patch, I would choose a simpler > popo_safe() as naming convention. That would be also more consistent > with the names applied to the refactored routines of 4246a977bad6. > The reason for this naming was to maintain consistency with the function date2timestamp_no_overflow() in date.h. I am now uncertain whether we should rename date2timestamp_no_overflow() as well to align with the current change. I also lean towards popo_safe() as a naming convention. > - result = date2timestamp_opt_overflow(val, &overflow); > + result = date2timestamp_overflow_safe(val, (Node *) &escontext); > /* We can ignore the overflow result, since result is useful as-is */ > > In these cases, why don't you just pass NULL to the routines for the > error context? (Sorry, I don't have my eyes on the code now, but I > recall that NULL should work as well, meaning the same as "ignore > me".) Won't that result in an error that we are trying to avoid? Regards, Amul
В списке pgsql-hackers по дате отправления: