Horton

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

Vik Fearing <vik@postgresfriends.org>

View thread
From: Vik Fearing <vik@postgresfriends.org>
To: Tom Lane <tgl@sss.pgh.pa.us>, Corey Huinker <corey.huinker@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2023-01-03T18:32:58Z
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 1/3/23 19:14, Tom Lane wrote:
> Corey Huinker <corey.huinker@gmail.com> writes:
>> On Mon, Jan 2, 2023 at 10:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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.
> 
>> I'm going off the spec that Vik presented in
>> https://www.postgresql.org/message-id/f8600a3b-f697-2577-8fea-f40d3e18bea8@postgresfriends.org
>> which is his effort to get it through the SQL committee.
> 
> I'm pretty certain that sending something to pgsql-hackers will have
> exactly zero impact on the SQL committee.  Is there anything actually
> submitted to the committee, and if so what's its status?

I have not posted my paper to the committee yet, but I plan to do so 
before the working group's meeting early February.  Just like with 
posting patches here, I cannot guarantee that it will get accepted but I 
will be arguing for it.

I don't think we should add that syntax until I do get it through the 
committee, just in case they change something.
-- 
Vik Fearing