On 24/07/2025 15:44, jian he wrote:
just want to confirm my understanding of ``[ FORMAT ]``.
SELECT CAST('2022-13-32' AS DATE FORMAT '-MM-DD' DEFAULT NULL ON
CONVERSION ERROR);
will return NULL.
because ``SELECT to_date('2022-13-32', '-MM-DD');``
will error out, so the above query wi
On 24/07/2025 03:22, jian he wrote:
+SELECT CAST('a' as int DEFAULT sum(1) ON CONVERSION ERROR); --error
+SELECT CAST('a' as int DEFAULT sum(1) over() ON CONVERSION ERROR); --error
This seems like an arbitrary restriction. Can you explain why this is
necessary? Those same expressions are a
On Tue, Jul 22, 2025 at 8:26 PM Vik Fearing wrote:
>
>
> On 22/07/2025 12:19, jian he wrote:
> > On Tue, Jul 22, 2025 at 2:45 PM Vik Fearing
> > wrote:
> >> It was accepted into the standard after 2023 was released. I am the
> >> author of this change in the standard, so feel free to ask me any
On Tue, Jul 22, 2025 at 8:26 PM Vik Fearing wrote:
>
> The actual syntax is:
>
>
> ::=
> CAST
> AS
> [ FORMAT ]
> [ ON CONVERSION ERROR ]
>
>
>
> "CONVERSION" is probably a noise word, but it is there because A) Oracle
> wanted it there, and B) it ma
On Tue, Jul 22, 2025 at 2:45 AM Vik Fearing wrote:
>
> On 22/07/2025 03:59, jian he wrote:
> > Based on my reading of [4], it seems CAST(EXPRESSION AS TYPE DEFAULT
> > def_expr ON ERROR)
> > is not included in SQL:2023.
> >
> > [4]
> https://peter.eisentraut.org/blog/2023/04/04/sql-2023-is-finish
On 22/07/2025 14:26, Vik Fearing wrote:
The is:
::=
ERROR
| NULL
| DEFAULT
but I am planning on removing the NULL variant in favor of having the
be a . So
it would be either ERROR ON CONVERSION ERROR (postgres's current
behavior), or DEFAULT NULL ON CONVERSION ERROR.
Sorry
On 22/07/2025 12:19, jian he wrote:
On Tue, Jul 22, 2025 at 2:45 PM Vik Fearing wrote:
It was accepted into the standard after 2023 was released. I am the
author of this change in the standard, so feel free to ask me anything
you're unsure about.
is the generally syntax as mentioned in thi
On Tue, Jul 22, 2025 at 2:45 PM Vik Fearing wrote:
>
> It was accepted into the standard after 2023 was released. I am the
> author of this change in the standard, so feel free to ask me anything
> you're unsure about.
>
is the generally syntax as mentioned in this thread:
CAST(source_expression
On 22/07/2025 03:59, jian he wrote:
Based on my reading of [4], it seems CAST(EXPRESSION AS TYPE DEFAULT
def_expr ON ERROR)
is not included in SQL:2023.
[4]https://peter.eisentraut.org/blog/2023/04/04/sql-2023-is-finished-here-is-whats-new
It was accepted into the standard after 2023 was re
hi.
more preparation work has been committed.
1. SQL/JSON patch [1] added keyword ERROR
2. CoerceViaIo, CoerceToDomain can be evaluated error safe. see commit [2].
3. ExprState added ErrorSaveContext point, so before calling ExecInitExprRec
set valid ErrorSaveContext for ExprState->escontext we sh
On Tue, Mar 28, 2023 at 3:25 PM Isaac Morland
wrote:
> On Mon, 19 Dec 2022 at 17:57, Corey Huinker
> wrote:
>
>>
>> Attached is my work in progress to implement the changes to the CAST()
>> function as proposed by Vik Fearing.
>>
>> CAST(expr AS typename NULL ON ERROR)
>> will use error-safe
On Tue, Mar 28, 2023 at 2:53 PM Gregory Stark (as CFM)
wrote:
> On Tue, 3 Jan 2023 at 14:16, Tom Lane wrote:
> >
> > Vik Fearing writes:
> >
> > > I don't think we should add that syntax until I do get it through the
> > > committee, just in case they change something.
> >
> > Agreed. So this
On Mon, 19 Dec 2022 at 17:57, Corey Huinker wrote:
>
> Attached is my work in progress to implement the changes to the CAST()
> function as proposed by Vik Fearing.
>
> CAST(expr AS typename NULL ON ERROR)
> will use error-safe functions to do the cast of expr, and will return
> NULL if the c
On Tue, 3 Jan 2023 at 14:16, Tom Lane wrote:
>
> Vik Fearing writes:
>
> > I don't think we should add that syntax until I do get it through the
> > committee, just in case they change something.
>
> Agreed. So this is something we won't be able to put into v16;
> it'll have to wait till there's
Vik Fearing writes:
> 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 tha
On 1/3/23 19:14, Tom Lane wrote:
Corey Huinker writes:
On Mon, Jan 2, 2023 at 10:57 AM Tom Lane 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
Corey Huinker writes:
> On Mon, Jan 2, 2023 at 10:57 AM Tom Lane 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
On Mon, Jan 2, 2023 at 10:57 AM Tom Lane wrote:
> Corey Huinker 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(
On 2023-01-02 Mo 10:57, Tom Lane wrote:
> Corey Huinker 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 typena
On Tue, 20 Dec 2022 at 04:27, Corey Huinker wrote:
>
>
> Attached is my work in progress to implement the changes to the CAST()
> function as proposed by Vik Fearing.
>
> This work builds upon the Error-safe User Functions work currently ongoing.
>
> The proposed changes are as follows:
>
> CAST(
Corey Huinker 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 functi
Attached is my work in progress to implement the changes to the CAST()
function as proposed by Vik Fearing.
This work builds upon the Error-safe User Functions work currently ongoing.
The proposed changes are as follows:
CAST(expr AS typename)
continues to behave as before.
CAST(expr AS typ
22 matches
Mail list logo
