Re: Error-safe user functions
От | Andrew Dunstan |
---|---|
Тема | Re: Error-safe user functions |
Дата | |
Msg-id | 9e04496c-2cab-ceec-5435-28305e1557f9@dunslane.net обсуждение исходный текст |
Ответ на | Re: Error-safe user functions (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2022-12-08 Th 17:57, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: >> On 2022-12-08 16:00:10 -0500, Robert Haas wrote: >>> Yes, I think just putting "struct Node;" in as many places as >>> necessary is the way to go. Or even: >> +1 > OK, here's a v5 that does it like that. > > I've spent a little time pushing ahead on other input functions, > and realized that my original plan to require a pre-encoded typmod > for these test functions was not very user-friendly. So in v5 > you can write something like > > pg_input_is_valid('1234.567', 'numeric(7,4)') > > 0004 attached finishes up the remaining core numeric datatypes > (int*, float*, numeric). I ripped out float8in_internal_opt_error > in favor of a function that uses the new APIs. Great, that takes care of some of the relatively urgent work. > > 0005 converts contrib/cube, which I chose to tackle partly because > I'd already touched it in 0004, partly because it seemed like a > good idea to verify that extension modules wouldn't have any > problems with this apprach, and partly because I wondered whether > an input function that uses a Bison/Flex parser would have big > problems getting converted. This one didn't, anyway. Cool > > Given that this additional experimentation didn't find any holes > in the API design, I think this is pretty much ready to go. > > I will look in more detail tomorrow, but it LGTM on a quick look. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: