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
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
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
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.
> 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.
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
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.)
>
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!
>
>
>>
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
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
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
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
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
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
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
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
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
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
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, _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.
>
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, _tmp, errMsg,
> > sizeof(errMsg));
Ted Yu writes:
> In makeItemLikeRegex :
> + /* See regexp.c for explanation */
> + CHECK_FOR_INTERRUPTS();
> + pg_regerror(re_result, _tmp, errMsg,
> sizeof(errMsg));
> + ereturn(escontext, false,
> Since an
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,
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
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
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)
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,
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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 the user does, say "CHECK (value > 0)" and that
> results in a
On 2022-Dec-09, Tom Lane wrote:
> I think though that it might be okay to just define this as
> Not Our Problem. Although we don't seem to try to enforce it,
> non-immutable domain check constraints are strongly deprecated
> (the CREATE DOMAIN man page says that we assume immutability).
> And
Andrew Dunstan writes:
> On 2022-12-09 Fr 10:16, Tom Lane wrote:
>> As I said, I'll take a look at the datetime area. Do we
>> have any volunteers for other input functions?
> I am currently looking at the json types. I think that will be enough to
> let us rework the sql/json patches as
On Fri, Dec 9, 2022 at 11:17 AM Amul Sul wrote:
> On Fri, Dec 9, 2022 at 9:08 PM Andrew Dunstan wrote:
> >
> >
> > On 2022-12-09 Fr 10:16, Tom Lane wrote:
> > > Andrew Dunstan writes:
> > >> On 2022-12-08 Th 21:59, Tom Lane wrote:
> > >>> Yeah, I was planning to take a look at that before
On Fri, Dec 9, 2022 at 9:08 PM Andrew Dunstan wrote:
>
>
> On 2022-12-09 Fr 10:16, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> On 2022-12-08 Th 21:59, Tom Lane wrote:
> >>> Yeah, I was planning to take a look at that before walking away from
> >>> this stuff. (I'm sure not volunteering to
On 2022-12-09 Fr 10:16, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-12-08 Th 21:59, Tom Lane wrote:
>>> Yeah, I was planning to take a look at that before walking away from
>>> this stuff. (I'm sure not volunteering to convert ALL the input
>>> functions, but I'll do the datetime
Andrew Dunstan writes:
> On 2022-12-08 Th 21:59, Tom Lane wrote:
>> Yeah, I was planning to take a look at that before walking away from
>> this stuff. (I'm sure not volunteering to convert ALL the input
>> functions, but I'll do the datetime code.)
> Awesome. Perhaps if there are no more
On 2022-12-08 Th 21:59, Tom Lane wrote:
> Andres Freund writes:
>> On 2022-12-08 17:57:09 -0500, Tom Lane wrote:
>>> Given that this additional experimentation didn't find any holes
>>> in the API design, I think this is pretty much ready to go.
>> One interesting area is timestamp / datetime
Andres Freund writes:
> On 2022-12-08 17:57:09 -0500, Tom Lane wrote:
>> Given that this additional experimentation didn't find any holes
>> in the API design, I think this is pretty much ready to go.
> One interesting area is timestamp / datetime related code. There's been some
> past efforts
Hi,
On 2022-12-08 17:57:09 -0500, Tom Lane wrote:
> Given that this additional experimentation didn't find any holes
> in the API design, I think this is pretty much ready to go.
One interesting area is timestamp / datetime related code. There's been some
past efforts in the area, mostly in
On 2022-12-08 Th 17:57, Tom Lane wrote:
> Andres Freund writes:
>> On 2022-12-08 16:00:10 -0500, Robert Haas wrote:
>>> Yes, I think just putting "struct Node;" in as many places as
>>> necessary is the way to go. Or even:
>> +1
> OK, here's a v5 that does it like that.
>
> I've spent a little
Andres Freund writes:
> On 2022-12-08 16:00:10 -0500, Robert Haas wrote:
>> Yes, I think just putting "struct Node;" in as many places as
>> necessary is the way to go. Or even:
> +1
OK, here's a v5 that does it like that.
I've spent a little time pushing ahead on other input functions,
and
Hi,
On 2022-12-08 16:00:10 -0500, Robert Haas wrote:
> On Thu, Dec 8, 2022 at 11:32 AM Tom Lane wrote:
> > If we go with "struct Node *" then we can solve such problems by
> > just repeating "struct Node;" forward-declarations in as many
> > headers as we have to.
>
> Yes, I think just putting
On Thu, Dec 8, 2022 at 11:32 AM Tom Lane wrote:
> If we go with "struct Node *" then we can solve such problems by
> just repeating "struct Node;" forward-declarations in as many
> headers as we have to.
Yes, I think just putting "struct Node;" in as many places as
necessary is the way to go. Or
Andres Freund writes:
> On 2022-12-07 17:32:21 -0500, Tom Lane wrote:
>> +typedef struct Node *NodePtr;
> Seems like it'd be easier to just forward declare the struct, and use the
> non-typedef'ed name in the header than to have to deal with these
> interdependencies and the differing typenames.
On 2022-Dec-07, David G. Johnston wrote:
> Are you suggesting we should not go down the path that v8-0003 does in the
> monitoring section cleanup thread? I find the usability of Chapter 54
> System Views to be superior to these two run-on chapters and would rather
> we emulate it in both these
On Wed, Dec 7, 2022 at 12:17 PM Tom Lane wrote:
> Corey Huinker writes:
> > In my attempt to implement CAST...DEFAULT, I noticed that I immediately
> > needed an
> > OidInputFunctionCallSafe, which was trivial but maybe something we want
> to
> > add to the infra patch, but the comments around
Andres Freund writes:
> I wonder if there are potential use-cases for levels other than ERROR. I can
> potentially see us wanting to defer some FATALs, e.g. when they occur in
> process exit hooks.
I thought about that early on, and concluded not. The whole thing is
moot for levels less than
Hi,
On 2022-12-07 17:32:21 -0500, Tom Lane wrote:
> I already pushed the elog-refactoring patch, since that seemed
> uncontroversial. 0001 attached covers the same territory as before,
> but I regrouped the rest so that 0002 installs the new test support
> functions, then 0003 adds both the
Andrew Dunstan writes:
> On 2022-12-07 We 17:32, Tom Lane wrote:
>> Does it make sense to break 0003 into 4 separate commits, or is
>> that overkill?)
> No strong opinion about 0001 and 0002. I'm happy enough with them as
> they are, but if you want to squash them that's ok. I wouldn't break up
On 2022-12-07 We 17:32, Tom Lane wrote:
> OK, here's a v4 that I think is possibly committable.
>
> I've changed all the comments and docs to use the "soft error"
> terminology, but since using "soft" in the actual function names
> didn't seem that appealing, they still use "safe".
>
> I already
OK, here's a v4 that I think is possibly committable.
I've changed all the comments and docs to use the "soft error"
terminology, but since using "soft" in the actual function names
didn't seem that appealing, they still use "safe".
I already pushed the elog-refactoring patch, since that
"David G. Johnston" writes:
> On Wed, Dec 7, 2022 at 8:04 AM Andrew Dunstan wrote:
>> I'm not sure InputFunctionCallSoft would be an improvement. Maybe
>> InputFunctionCallSoftError would be clearer, but I don't know that it's
>> much of an improvement either. The same goes for the other visible
I wrote:
> Andres Freund writes:
>> Is there a guarantee that input functions are stable or immutable?
> There's a project policy that that should be true. That justifies
> marking things like record_in as stable --- if the per-column input
> functions could be volatile, record_in would need to
Andres Freund writes:
> Is there a guarantee that input functions are stable or immutable?
There's a project policy that that should be true. That justifies
marking things like record_in as stable --- if the per-column input
functions could be volatile, record_in would need to be as well.
There
On Wed, Dec 7, 2022 at 10:34 AM Andres Freund wrote:
> > +{ oid => '8053',
> > + descr => 'get error message if string is not valid input for data
> type',
> > + proname => 'pg_input_invalid_message', provolatile => 's',
> > + prorettype => 'text', proargtypes => 'text regtype int4',
> > +
Hi,
On 2022-12-06 15:21:09 -0500, Tom Lane wrote:
> +{ oid => '8050', descr => 'test whether string is valid input for data type',
> + proname => 'pg_input_is_valid', provolatile => 's', prorettype => 'bool',
> + proargtypes => 'text regtype', prosrc => 'pg_input_is_valid' },
> +{ oid =>
"David G. Johnston" writes:
> So long as you aren't opposed to the idea if someone else does the work,
> adding sect2 is better than nothing even if it is just a stop-gap measure.
OK, we can agree on that.
As for the other point --- not sure why I didn't remember this right off,
but the point
Corey Huinker writes:
> In my attempt to implement CAST...DEFAULT, I noticed that I immediately
> needed an
> OidInputFunctionCallSafe, which was trivial but maybe something we want to
> add to the infra patch, but the comments around that function also somewhat
> indicate that we might want to
On 2022-12-07 09:20:33 -0500, Tom Lane wrote:
> Returning to the naming quagmire -- it occurred to me just now that
> it might be helpful to call this style of error reporting "soft"
> errors rather than "safe" errors, which'd provide a nice contrast
> with "hard" errors thrown by longjmp'ing.
+1
On Wed, Dec 7, 2022 at 9:59 AM Tom Lane wrote:
> "David G. Johnston" writes:
>
> > Are you suggesting we should not go down the path that v8-0003 does in
> the
> > monitoring section cleanup thread? I find the usability of Chapter 54
> > System Views to be superior to these two run-on chapters
On Wed, Dec 7, 2022 at 9:20 AM Tom Lane wrote:
> Andrew Dunstan writes:
> > Perhaps we should add a type in the regress library that will never have
> > a safe input function, so we can test that the mechanism works as
> > expected in that case even after we adjust all the core data types'
> >
"David G. Johnston" writes:
> On Wed, Dec 7, 2022 at 9:06 AM Tom Lane wrote:
>> "David G. Johnston" writes:
>>> Why not do away with two separate functions and define a composite type
>>> (boolean, text) for is_valid to return?
>> I don't see any advantage to that. It would be harder to use
On Wed, Dec 7, 2022 at 9:06 AM Tom Lane wrote:
> "David G. Johnston" writes:
> > Why not do away with two separate functions and define a composite type
> > (boolean, text) for is_valid to return?
>
> I don't see any advantage to that. It would be harder to use in both
> use-cases.
>
I don't
"David G. Johnston" writes:
> Why not do away with two separate functions and define a composite type
> (boolean, text) for is_valid to return?
I don't see any advantage to that. It would be harder to use in both
use-cases.
>> BTW, does anyone else agree that 9.26 is desperately in need of
On Wed, Dec 7, 2022 at 8:23 AM Tom Lane wrote:
> Andrew Dunstan writes:
> > On 2022-12-07 We 09:20, Tom Lane wrote:
> >> Returning to the naming quagmire -- it occurred to me just now that
> >> it might be helpful to call this style of error reporting "soft"
> >> errors rather than "safe"
On Wed, Dec 7, 2022 at 8:04 AM Andrew Dunstan wrote:
>
> On 2022-12-07 We 09:20, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> Perhaps we should add a type in the regress library that will never have
> >> a safe input function, so we can test that the mechanism works as
> >> expected in that
1 - 100 of 173 matches
Mail list logo
