On Tue, Nov 25, 2025 at 8:30 AM jian he wrote:
>
> On Mon, Nov 24, 2025 at 11:38 AM Amul Sul wrote:
> >
> > [...]
> +static inline float8
> +float8_div_safe(const float8 val1, const float8 val2, struct Node *escontext)
>
> but we can change float8_div to:
>
> static inline float8
> float8_div(con
>
> >> I'm fine with it. I can see having 'f' and 's' both mean cast
> functions, but 's' means safe, but the extra boolean works too and we'll be
> fine with either method.
> >
> >
> > I can work on this part if you don't have time.
>
> Do you mean change pg_cast.casterrorsafe from boolean to char
On Fri, Nov 21, 2025 at 2:11 PM jian he wrote:
>
> On Mon, Nov 17, 2025 at 9:43 PM Amul Sul wrote:
> >
> > 10-0004:
> >
> > +/* error safe version of textToQualifiedNameList */
> > +List *
> > +textToQualifiedNameListSafe(text *textval, Node *escontext)
> >
> > If I am not mistaken, it looks like
>
> > The same logic applies to RangeVarGetRelidExtendedSafe() and
> > makeRangeVarFromNameListSafe. These can be called from
> > RangeVarGetRelidExtended() and makeRangeVarFromNameList(),
> > respectively.
> > --
> >
>
> I don’t see any way to pass the escontext (ErrorSaveContext) without
> changi
On Mon, Nov 17, 2025 at 9:43 PM Amul Sul wrote:
>
> 10-0004:
>
> +/* error safe version of textToQualifiedNameList */
> +List *
> +textToQualifiedNameListSafe(text *textval, Node *escontext)
>
> If I am not mistaken, it looks like an exact copy of
> textToQualifiedNameList(). I think you can simpl
On Mon, Nov 10, 2025 at 11:36 PM Corey Huinker
wrote:
> As mentioned before, to make
>> CAST(source_expr AS target_type DEFAULT expr ON CONVERSION ERROR);
>> work,
>> we cannot just simply replace casting FuncExpr nodes with CoerceViaIO,
>> since
>> type modifiers behave differently in these two
On Tue, Nov 11, 2025 at 8:37 AM jian he wrote:
>
> On Thu, Nov 6, 2025 at 6:00 AM Corey Huinker wrote:
> > [...]
>
> Currently, patches v9-0001 through v9-0018 focus solely on refactoring
> pg_cast.castfunc.
I had a quick look but haven't finished the full review due to lack of
time today. Here
>
> As mentioned before, to make
> CAST(source_expr AS target_type DEFAULT expr ON CONVERSION ERROR);
> work,
> we cannot just simply replace casting FuncExpr nodes with CoerceViaIO,
> since
> type modifiers behave differently in these two Nodes.
> (e.g., casting numeric 1.11 to integer is not equi
>
> The above result shows type casts using functions which cannot be error
> safe.
> Money type related casts still can not be error safe.
>
> Cast from circle to polygon cannot be error safe because the associated
> cast
> function (pg_cast.castfunc) is written in SQL
> (see src/backend/catalog/s
>
>
> In the end, it seems we need to make all these functions in the below
> query error safe.
> select castsource::regtype, casttarget::regtype, castfunc,
> castcontext,castmethod, pp.prosrc, pp.proname from pg_cast pc join pg_proc
> pp on
> pp.oid = pc.castfunc and pc.castfunc > 0
> order by cas
On Mon, Aug 4, 2025 at 1:09 PM Corey Huinker wrote:
>>
>> so we need to handle numeric source types with fractional points with
>> special care.
>> currently, this applies only to numeric, float4, and float8.
>> (hope this is all the corner case we need to catch...)
>
>
> I'm fairly certain that t
>
> so we need to handle numeric source types with fractional points with
> special care.
> currently, this applies only to numeric, float4, and float8.
> (hope this is all the corner case we need to catch...)
>
I'm fairly certain that the committers won't like us special-casing the
internal cast
hi.
fix the regress tests failure in
https://api.cirrus-ci.com/v1/artifact/task/5894868779663360/testrun/build/testrun/regress/regress/regression.diffs
From e60e5190511326568eba8e6748062adb47f1134c Mon Sep 17 00:00:00 2001
From: jian he
Date: Fri, 18 Jul 2025 13:00:19 +0800
Subject: [PATCH v4 2/3
On Thu, Jul 31, 2025 at 3:15 AM Corey Huinker wrote:
>
>
> Question about this:
>
> +/*
> + * Push steps to evaluate a SafeTypeCastExpr and its various subsidiary
> expressions.
> + * We already handle CoerceViaIO, CoerceToDomain, and ArrayCoerceExpr error
> + * softly. However, FuncExpr (e.g.,
>
>
> I didn't implement the [ FORMAT ] part for now.
> please check the attached regress test and tests expected result.
>
Question about this:
+/*
+ * Push steps to evaluate a SafeTypeCastExpr and its various subsidiary
expressions.
+ * We already handle CoerceViaIO, CoerceToDomain, and ArrayC
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
On Sun, Dec 25, 2022 at 12:13 PM Tom Lane wrote:
> Here's a proposed patch for converting regprocin and friends
> to soft error reporting. I'll say at the outset that it's an
> engineering compromise, and it may be worth going further in
> future. But I doubt it's worth doing more than this for
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
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
On 2022-12-28 We 01:00, Amul Sul wrote:
> On Tue, Dec 27, 2022 at 11:17 PM Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Here's a patch that covers the ltree and intarray contrib modules.
>> I would probably have done this a little differently --- I think
>> the added "res" parameters aren't re
On Tue, Dec 27, 2022 at 11:17 PM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > Here's a patch that covers the ltree and intarray contrib modules.
>
> I would probably have done this a little differently --- I think
> the added "res" parameters aren't really necessary for most of
> these. But it
Andrew Dunstan writes:
> On Dec 27, 2022, at 12:47 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> I think that would leave just hstore to be done.
>> Yeah, that matches my scoreboard. Are you going to look at
>> hstore, or do you want me to?
> Go for it.
Done.
r
> On Dec 27, 2022, at 12:47 PM, Tom Lane wrote:
>
> Andrew Dunstan writes:
>> Here's a patch that covers the ltree and intarray contrib modules.
>
> I would probably have done this a little differently --- I think
> the added "res" parameters aren't really necessary for most of
> these. Bu
Andrew Dunstan writes:
> Here's a patch that covers the ltree and intarray contrib modules.
I would probably have done this a little differently --- I think
the added "res" parameters aren't really necessary for most of
these. But it's not worth arguing over.
> I think that would leave just hst
On 2022-12-26 Mo 18:00, Tom Lane wrote:
> I wrote:
>> (Perhaps we should go further than this, and convert all these
>> functions to just be DirectInputFunctionCallSafe wrappers
>> around the corresponding input functions? That would save
>> some duplicative code, but I've not done it here.)
> I
On 2022-12-26 Mo 14:12, Andrew Dunstan wrote:
> On 2022-12-26 Mo 12:47, Tom Lane wrote:
>> Here's a proposed patch for making tsvectorin and tsqueryin
>> report errors softly. We have to take the changes down a
>> couple of levels of subroutines, but it's not hugely difficult.
>
> Great!
>
>
>> W
I wrote:
> (Perhaps we should go further than this, and convert all these
> functions to just be DirectInputFunctionCallSafe wrappers
> around the corresponding input functions? That would save
> some duplicative code, but I've not done it here.)
I looked closer at that idea, and realized that it
On 2022-12-26 Mo 12:47, Tom Lane wrote:
> Here's a proposed patch for making tsvectorin and tsqueryin
> report errors softly. We have to take the changes down a
> couple of levels of subroutines, but it's not hugely difficult.
Great!
>
> With the other patches I've posted recently, this cove
Here's a proposed patch for making tsvectorin and tsqueryin
report errors softly. We have to take the changes down a
couple of levels of subroutines, but it's not hugely difficult.
A couple of points worthy of comment:
* To reduce API changes, I made the functions in
tsvector_parser.c and tsquer
On 2022-12-25 Su 12:13, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Dec 16, 2022 at 1:31 PM Tom Lane wrote:
>>> The reg* functions probably need a unified plan as to how far
>>> down we want to push non-error behavior.
>> I would be in favor of an aggressive approach.
> Here's a proposed p
I got annoyed by the fact that types cid, xid, xid8 don't throw
error even for obvious garbage, because they just believe the
result of strtoul or strtoull without any checking. That was
probably up to project standards when cidin and xidin were
written; but surely it's not anymore, especially whe
Robert Haas writes:
> On Fri, Dec 16, 2022 at 1:31 PM Tom Lane wrote:
>> The reg* functions probably need a unified plan as to how far
>> down we want to push non-error behavior.
> I would be in favor of an aggressive approach.
Here's a proposed patch for converting regprocin and friends
to sof
On 2022-12-24 Sa 10:42, Tom Lane wrote:
> Andrew Dunstan writes:
>> As I was giving this a final polish I noticed this in jspConvertRegexFlags:
>> /*
>> * We'll never need sub-match details at execution. While
>> * RE_compile_and_execute would set this flag anyway, force it on her
Ted Yu writes:
> On Fri, Dec 23, 2022 at 1:22 PM Tom Lane wrote:
>> Yes, it is. We don't want a query-cancel transformed into a soft error.
> The same regex, without user interruption, would exhibit an `invalid
> regular expression` error.
On what grounds do you claim that? The timing of arri
Andrew Dunstan writes:
> As I was giving this a final polish I noticed this in jspConvertRegexFlags:
> /*
> * We'll never need sub-match details at execution. While
> * RE_compile_and_execute would set this flag anyway, force it on here to
> * ensure that the regex cache entri
On Sat, Dec 24, 2022 at 4:38 AM Andrew Dunstan wrote:
>
> On 2022-12-24 Sa 04:51, Ted Yu wrote:
> >
> >
> > On Fri, Dec 23, 2022 at 1:22 PM Tom Lane wrote:
> >
> > Ted Yu writes:
> > > In makeItemLikeRegex :
> >
> > > + /* See regexp.c for explanation */
> >
On 2022-12-23 Fr 13:53, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-12-22 Th 11:44, Tom Lane wrote:
>>> (I wonder why this is using RE_compile_and_cache at all, really,
>>> rather than some other API. There doesn't seem to be value in
>>> forcing the regex into the cache at this point.)
On 2022-12-24 Sa 04:51, Ted Yu wrote:
>
>
> On Fri, Dec 23, 2022 at 1:22 PM Tom Lane wrote:
>
> Ted Yu writes:
> > In makeItemLikeRegex :
>
> > + /* See regexp.c for explanation */
> > + CHECK_FOR_INTERRUPTS();
> > +
On Fri, Dec 23, 2022 at 1:22 PM Tom Lane wrote:
> Ted Yu writes:
> > In makeItemLikeRegex :
>
> > + /* See regexp.c for explanation */
> > + CHECK_FOR_INTERRUPTS();
> > + pg_regerror(re_result, &re_tmp, errMsg,
> > sizeof(errMsg))
Ted Yu writes:
> On Fri, Dec 23, 2022 at 1:22 PM Tom Lane wrote:
>> Ted Yu writes:
>>> + /* See regexp.c for explanation */
>>> + CHECK_FOR_INTERRUPTS();
>> Yes, it is. We don't want a query-cancel transformed into a soft error.
> `ereturn(escontext
On Fri, Dec 23, 2022 at 1:22 PM Tom Lane wrote:
> Ted Yu writes:
> > In makeItemLikeRegex :
>
> > + /* See regexp.c for explanation */
> > + CHECK_FOR_INTERRUPTS();
> > + pg_regerror(re_result, &re_tmp, errMsg,
> > sizeof(errMsg))
Ted Yu writes:
> In makeItemLikeRegex :
> + /* See regexp.c for explanation */
> + CHECK_FOR_INTERRUPTS();
> + pg_regerror(re_result, &re_tmp, errMsg,
> sizeof(errMsg));
> + ereturn(escontext, false,
> Since
On Fri, Dec 23, 2022 at 9:20 AM Andrew Dunstan wrote:
>
> On 2022-12-22 Th 11:44, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> Yeah, I started there, but it's substantially more complex - unlike cube
> >> the jsonpath scanner calls the error routines as well as the parser.
> >> Anyway, here's
Andrew Dunstan writes:
> On 2022-12-22 Th 11:44, Tom Lane wrote:
>> (I wonder why this is using RE_compile_and_cache at all, really,
>> rather than some other API. There doesn't seem to be value in
>> forcing the regex into the cache at this point.)
> I agree. The attached uses pg_regcomp instea
On 2022-12-22 Th 11:44, Tom Lane wrote:
> Andrew Dunstan writes:
>> Yeah, I started there, but it's substantially more complex - unlike cube
>> the jsonpath scanner calls the error routines as well as the parser.
>> Anyway, here's a patch.
> I looked through this and it seems generally OK. A min
On 2022-12-22 Th 01:10, Tom Lane wrote:
> Andrew Dunstan writes:
>> And here's another for contrib/seg
>> I'm planning to commit these two in the next day or so.
> I didn't look at the jsonpath one yet. The seg patch passes
> an eyeball check, with one minor nit: in seg_atof,
>
> + *result
Andrew Dunstan writes:
> Yeah, I started there, but it's substantially more complex - unlike cube
> the jsonpath scanner calls the error routines as well as the parser.
> Anyway, here's a patch.
I looked through this and it seems generally OK. A minor nitpick is
that we usually write "(Datum) 0"
Andrew Dunstan writes:
> And here's another for contrib/seg
> I'm planning to commit these two in the next day or so.
I didn't look at the jsonpath one yet. The seg patch passes
an eyeball check, with one minor nit: in seg_atof,
+ *result = float4in_internal(value, NULL, "real", value, es
On 2022-12-18 Su 09:42, Andrew Dunstan wrote:
> On 2022-12-14 We 17:37, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Thanks, I have been looking at jsonpath, but I'm not quite sure how to
>>> get the escontext argument to the yyerror calls in jsonath_scan.l. Maybe
>>> I need to specify a lex-par
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
On Mon, Dec 19, 2022 at 4:27 PM Tom Lane wrote:
> In [1] I wrote
>
> >>> I'm a little concerned about the cost-benefit of fixing the reg* types.
> >>> The ones that accept type names actually use the core grammar to parse
> >>> those. Now, we probably could fix the grammar to be non-throwing, but
Robert Haas writes:
> On Mon, Dec 19, 2022 at 11:44 AM Tom Lane wrote:
>> ... I guess you didn't read my remarks upthread about regtypein.
>> I do not want to try to make gram.y+scan.l non-error-throwing.
> Huh, for some reason I'm not seeing an email about that. Do you have a link?
In [1] I wr
On Mon, Dec 19, 2022 at 11:44 AM Tom Lane wrote:
> > It also doesn't seem too bad from an implementation point of view to
> > try to cover all the caes.
>
> ... I guess you didn't read my remarks upthread about regtypein.
> I do not want to try to make gram.y+scan.l non-error-throwing.
Huh, for s
Robert Haas writes:
> On Fri, Dec 16, 2022 at 1:31 PM Tom Lane wrote:
>> The reg* functions probably need a unified plan as to how far
>> down we want to push non-error behavior. The rest of these
>> I think just require turning the crank along the same lines
>> as in functions already dealt wit
On Fri, Dec 16, 2022 at 1:31 PM Tom Lane wrote:
> The reg* functions probably need a unified plan as to how far
> down we want to push non-error behavior. The rest of these
> I think just require turning the crank along the same lines
> as in functions already dealt with.
I would be in favor of
On 2022-12-14 We 17:37, Tom Lane wrote:
> Andrew Dunstan writes:
>> Thanks, I have been looking at jsonpath, but I'm not quite sure how to
>> get the escontext argument to the yyerror calls in jsonath_scan.l. Maybe
>> I need to specify a lex-param setting?
> You want a parse-param option in jsonp
On 2022-12-15 Th 09:12, Robert Haas wrote:
> On Wed, Dec 14, 2022 at 6:24 PM Tom Lane wrote:
>> I've gone through these now and revised/pushed most of them.
> Tom, I just want to extend huge thanks to you for working on this
> infrastructure. jsonpath aside, I think this is going to pay dividend
I wrote:
> I'm going to step back from this for now and get on with other work,
> but before that I thought there was one more input function I should
> look at: xml_in, because xml.c is such a hairy can of worms.
Pushed that. For the record, my list of input functions still needing
attention sta
Robert Haas writes:
> Tom, I just want to extend huge thanks to you for working on this
> infrastructure.
Thanks. I agree it's an important bit of work.
I'm going to step back from this for now and get on with other work,
but before that I thought there was one more input function I should
look
On Wed, Dec 14, 2022 at 6:24 PM Tom Lane wrote:
> I've gone through these now and revised/pushed most of them.
Tom, I just want to extend huge thanks to you for working on this
infrastructure. jsonpath aside, I think this is going to pay dividends
in many ways for many years to come. It's somethi
On Thu, Dec 15, 2022 at 11:16 AM Tom Lane wrote:
>
> Amul Sul writes:
> > There are other a bunch of hard errors from get_multirange_io_data(),
> > get_range_io_data() and its subroutine can hit, shouldn't we care
> > about those?
>
> I think those are all "internal" errors, ie not reachable as a
Amul Sul writes:
> There are other a bunch of hard errors from get_multirange_io_data(),
> get_range_io_data() and its subroutine can hit, shouldn't we care
> about those?
I think those are all "internal" errors, ie not reachable as a
consequence of bad input data. Do you see a reason to think
d
On Thu, Dec 15, 2022 at 9:03 AM Tom Lane wrote:
>
> Here are some proposed patches for converting range_in and multirange_in.
>
> 0001 tackles the straightforward part, which is trapping syntax errors
> and called-input-function errors. The only thing that I think might
> be controversial here is
Here are some proposed patches for converting range_in and multirange_in.
0001 tackles the straightforward part, which is trapping syntax errors
and called-input-function errors. The only thing that I think might
be controversial here is that I chose to change the signatures of
the exposed functi
I wrote:
> Amul Sul writes:
>> Attaching a complete set of the patches changing function till this
>> except bpcharin, byteain jsonpath_in that Andrew is planning to look
>> in. I have skipped reg* functions.
> I'll take a look at these shortly, unless Andrew is already on it.
I've gone through
Andrew Dunstan writes:
> Thanks, I have been looking at jsonpath, but I'm not quite sure how to
> get the escontext argument to the yyerror calls in jsonath_scan.l. Maybe
> I need to specify a lex-param setting?
You want a parse-param option in jsonpath_gram.y, I think; adding that
will persuade
On 2022-12-14 We 11:00, Tom Lane wrote:
> Amul Sul writes:
>> Attaching a complete set of the patches changing function till this
>> except bpcharin, byteain jsonpath_in that Andrew is planning to look
>> in. I have skipped reg* functions.
> I'll take a look at these shortly, unless Andrew is al
Amul Sul writes:
> Attaching a complete set of the patches changing function till this
> except bpcharin, byteain jsonpath_in that Andrew is planning to look
> in. I have skipped reg* functions.
I'll take a look at these shortly, unless Andrew is already on it.
regards, t
On Mon, Dec 12, 2022 at 12:00 AM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > Maybe as we work through the remaining input functions (there are about
> > 60 core candidates left on my list) we should mark them with a comment
> > if no adjustment is needed.
>
> I did a quick pass through them la
Andres Freund writes:
> On 2022-12-11 12:24:11 -0500, Tom Lane wrote:
>> I spent some time looking at this, and was discouraged to conclude
>> that the notational mess would probably be substantially out of
>> proportion to the value. The main problem is that we'd have to change
>> the API of pus
Hi,
On 2022-12-11 12:24:11 -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 2022-12-10 Sa 14:38, Tom Lane wrote:
> >> I have not done anything here about errors within JsonbValueToJsonb.
> >> There would need to be another round of API-extension in that area
> >> if we want to be able to tr
Andrew Dunstan writes:
> Maybe as we work through the remaining input functions (there are about
> 60 core candidates left on my list) we should mark them with a comment
> if no adjustment is needed.
I did a quick pass through them last night. Assuming that we don't
need to touch the unimplement
On 2022-12-11 Su 12:24, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-12-10 Sa 14:38, Tom Lane wrote:
>>> I have not done anything here about errors within JsonbValueToJsonb.
>>> There would need to be another round of API-extension in that area
>>> if we want to be able to trap its errors
Andrew Dunstan writes:
> On 2022-12-10 Sa 14:38, Tom Lane wrote:
>> I have not done anything here about errors within JsonbValueToJsonb.
>> There would need to be another round of API-extension in that area
>> if we want to be able to trap its errors. As you say, those are mostly
>> about exceedi
On 2022-12-10 Sa 19:00, Tom Lane wrote:
> Looking at my notes, there's one other loose end
> I forgot to mention:
>
> * Note: pg_unicode_to_server() will throw an error for a
> * conversion failure, rather than returning a failure
> *
Andrew Dunstan writes:
> On 2022-12-10 Sa 14:38, Tom Lane wrote:
>> Seeing that SQL/JSON is one of the major drivers of this whole project,
>> it seemed a little sad to me that jsonb couldn't manage to implement
>> what is required. So I spent a bit of time poking at it. Attached
>> is an extend
On 2022-12-10 Sa 14:38, Tom Lane wrote:
> Andrew Dunstan writes:
>> OK, json is a fairly easy case, see attached. But jsonb is a different
>> kettle of fish. Both the semantic routines called by the parser and the
>> subsequent call to JsonbValueToJsonb() can raise errors. These are
>> pretty mu
Corey Huinker writes:
> On Sat, Dec 10, 2022 at 9:20 AM Tom Lane wrote:
>> A fallback we can offer to anyone with such a problem is "write a
>> plpgsql function and wrap the potentially-failing bit in an exception
>> block". Then they get to pay the cost of the subtransaction, while
>> we're not
Andrew Dunstan writes:
> OK, json is a fairly easy case, see attached. But jsonb is a different
> kettle of fish. Both the semantic routines called by the parser and the
> subsequent call to JsonbValueToJsonb() can raise errors. These are
> pretty much all about breaking various limits (for string
On Sat, Dec 10, 2022 at 9:20 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2022-Dec-09, Tom Lane wrote:
> >> ... So I think it might be
> >> okay to say "if you want soft error treatment for a domain,
> >> make sure its check constraints don't throw errors".
>
> > I think that's fine. If
so 10. 12. 2022 v 15:35 odesílatel Andrew Dunstan
napsal:
>
> On 2022-12-09 Fr 10:37, Andrew Dunstan wrote:
> > I am currently looking at the json types. I think that will be enough to
> > let us rework the sql/json patches as discussed a couple of months ago.
> >
>
> OK, json is a fairly easy ca
On 2022-12-09 Fr 10:37, Andrew Dunstan wrote:
> I am currently looking at the json types. I think that will be enough to
> let us rework the sql/json patches as discussed a couple of months ago.
>
OK, json is a fairly easy case, see attached. But jsonb is a different
kettle of fish. Both the sema
1 - 100 of 211 matches
Mail list logo
