Horton

Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions

Andrew Dunstan <andrew@dunslane.net>

View thread
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>, Corey Huinker <corey.huinker@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2023-01-03T17:08:56Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make cast functions to type money error safe

  2. Make cast function from circle to polygon error safe

  3. Make geometry cast functions error safe

  4. Make cast functions from jsonb error safe

  5. Make many cast functions error safe

  6. Add SQL/JSON query functions

  7. Add soft error handling to some expression nodes

On 2023-01-02 Mo 10:57, Tom Lane wrote:
> Corey Huinker <corey.huinker@gmail.com> writes:
>> The proposed changes are as follows:
>> CAST(expr AS typename)
>>     continues to behave as before.
>> CAST(expr AS typename ERROR ON ERROR)
>>     has the identical behavior as the unadorned CAST() above.
>> CAST(expr AS typename NULL ON ERROR)
>>     will use error-safe functions to do the cast of expr, and will return
>> NULL if the cast fails.
>> CAST(expr AS typename DEFAULT expr2 ON ERROR)
>>     will use error-safe functions to do the cast of expr, and will return
>> expr2 if the cast fails.
> While I approve of trying to get some functionality in this area,
> I'm not sure that extending CAST is a great idea, because I'm afraid
> that the SQL committee will do something that conflicts with it.
> If we know that they are about to standardize exactly this syntax,
> where is that information available?  If we don't know that,
> I'd prefer to invent some kind of function or other instead of
> extending the grammar.


+1


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com