public inbox for [email protected]  
help / color / mirror / Atom feed
From: Corey Huinker <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: jian he <[email protected]>
Cc: Amul Sul <[email protected]>
Cc: Kirill Reshke <[email protected]>
Cc: Vik Fearing <[email protected]>
Cc: Isaac Morland <[email protected]>
Cc: [email protected]
Subject: Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions
Date: Tue, 24 Mar 2026 14:57:27 -0400
Message-ID: <CADkLM=cuzki8H9kqmbFqkk8bk7sxNbTGGyQ14edNGLGdnkxarg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CADkLM=fv1JfY4Ufa-jcwwNbjQixNViskQ8jZu3Tz_p656i_4hQ@mail.gmail.com>
	<CACJufxHGxB7KPAStUHZcWhFEDXsnU06qOugh60X4hHG6J-xoUA@mail.gmail.com>
	<CADkLM=f0xruKRH+6XvCsM1EVic9y4BL4AFo3VUfvRLdu-Qp5Gg@mail.gmail.com>
	<CADkLM=e4y2bLv-6_JY5c6vC9QtweW9VfxVmVJFpcriy8Rs23TA@mail.gmail.com>
	<CACJufxGO_qmyGjBvkwhCZzm6bWiqj8iyd1dGbL+_guok6yPMCQ@mail.gmail.com>
	<CADkLM=cZ7N+f4Bj-8MiccFcTASjBB2r1_s3BD9OFbbQOwK01cg@mail.gmail.com>
	<CACJufxE7yoH42juViFvYuCQMPwXMWxDVwiugs-BW+N4oUXB=1w@mail.gmail.com>
	<CADkLM=dFZ8-mBJDkiZZ4JadnJy8zLExUoo_b1FOs2Ozrtge=gQ@mail.gmail.com>
	<CACJufxHynx40aHHUCR4wZh1qnL=X0yw6baW4Z-+vkUgT0OhjOg@mail.gmail.com>
	<CADkLM=eCPiVhGKcbNW5bUEYpozUaKNXjd_UmBVR256p2zWtYQQ@mail.gmail.com>
	<CACJufxH4LrCpL63SRYO3zVk46YdD4--VYQoBL7GmHmCm=NCAJQ@mail.gmail.com>
	<CADkLM=cmv_bmxBe8KmZd6rEgiqSdoDfHnJa63u7rdRuAsqOwDA@mail.gmail.com>
	<CACJufxGbw9iNT8QVm4QD9cPFKnDnvDBQp7AGxkoqDa-JjzVXmg@mail.gmail.com>
	<CACJufxFkLLuX1VJ-J3fppCr37PHtxkvwyd_e4zNd+VYK0v0gnQ@mail.gmail.com>
	<[email protected]>

>
> In the comment for patch 0021 you write that the function casting type
> circle to type polygon cannot be error safe, because it's a SQL
> language function.  I suggest to convert this to a C function and make
> the required changes there.
>


> About the main feature patch: I'm not a fan of the CREATE CAST
> ... WITH SAFE FUNCTION syntax.  First, the CREATE CAST syntax is part
> of the SQL standard.  It would be weird if we needed a nonstandard
> syntax to make two standard features work together.  Second, we didn't
> do this when we introduced error-safe type input functions.  There is
> a note on the CREATE TYPE man page that use of ereturn() is
> encouraged, and then we left it to extension authors to do the right
> thing.  (And we should now put a similar note on the CREATE CAST man
> page.)  And third, requiring this would require a lot of churn in all
> affected extensions, requiring new extension SQL files and forcing
> upgrades.  The changes you did in patch 0023 don't do this correctly,
> for example.


This leaves us in a tricky situation if we can't tell ahead of time if a
cast function really can handle soft errors. We could just allow any and
all (CAST ... ON ERROR) calls even if the casting function can't actually
return soft errors. That's unfortunate, but it might be the simplest and
best way forward given that the alternative is to raise an error at planner
time guaranteeing a query failure when the values presented might not have
triggered the conversion errors.


> Tactical suggestion: Add an SQL-callable function, say,
> pg_cast_conversion_succeeds(srcvalue, desttype) that checks whether
> the cast would succeed.  This would be similar to the
> pg_input_is_valid() function that we added to test the type input
> functions.  (I did not call my proposal pg_cast_is_valid() because
> that might indicate merely that a casting path exists.)  With that,
> the higher-level functionality can be constructed by hand (CASE WHEN
> pg_cast_conversion_succeeds(...) THEN CAST(...) ELSE 'default value'
> END).  And then we can later work on building out the higher-level
> functionality and make more cast functions error safe.


You're describing the the "x IS CASTABLE AS y" syntax proposed in the same
standards proposal document :)


view thread (75+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions
  In-Reply-To: <CADkLM=cuzki8H9kqmbFqkk8bk7sxNbTGGyQ14edNGLGdnkxarg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox