On Tue, Feb 28, 2023 at 09:01:48AM +0900, Michael Paquier wrote:
> On Mon, Feb 27, 2023 at 11:25:01AM -0800, Nathan Bossart wrote:
>> I found a couple of more small changes required to make cfbot happy.
>> Otherwise, it looks good to me.
>
> Thanks, I have confirmed the spots the CI was
On Mon, Feb 27, 2023 at 11:25:01AM -0800, Nathan Bossart wrote:
> I found a couple of more small changes required to make cfbot happy.
> Otherwise, it looks good to me.
Thanks, I have confirmed the spots the CI was complaining about, so
applied. There was an extra place that was not right in
On Sat, Feb 25, 2023 at 08:58:17PM -0800, Nathan Bossart wrote:
> pg_input_error_info() seems more descriptive to me. I changed the name to
> that in v4.
error_info() is fine by me. My recent history is poor lately when it
comes to name new things.
+ values[0] =
On Sat, Feb 25, 2023 at 08:07:33PM -0500, Tom Lane wrote:
> Maybe pg_input_error_info()? I tend to agree with Michael that as
> soon as you throw things like the SQLSTATE code into it, "message"
> seems not very apropos. I'm not dead set on that position, though.
pg_input_error_info() seems
Nathan Bossart writes:
> On Sat, Feb 25, 2023 at 01:39:21PM +0900, Michael Paquier wrote:
>> pg_input_error_message() does not strike me as a good function name,
>> though, because it now returns much more than an error message.
>> Hence, couldn't something like pg_input_error() be better,
On Sat, Feb 25, 2023 at 01:39:21PM +0900, Michael Paquier wrote:
> pg_input_error_message() does not strike me as a good function name,
> though, because it now returns much more than an error message.
> Hence, couldn't something like pg_input_error() be better, because
> more generic?
I
On Fri, Feb 24, 2023 at 05:36:42PM -0500, Corey Huinker wrote:
> Looks good to me, passes make check-world. Thanks for slogging through this.
FWIW, I agree that switching pg_input_error_message() to return a row
would be nicer in the long-run than just getting an error message
because it has the
On Thu, Feb 23, 2023 at 4:47 PM Nathan Bossart
wrote:
> On Thu, Feb 23, 2023 at 11:30:38AM -0800, Nathan Bossart wrote:
> > Will post a new version shortly.
>
> As promised...
>
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
Looks good to me, passes make check-world.
On Thu, Feb 23, 2023 at 11:30:38AM -0800, Nathan Bossart wrote:
> Will post a new version shortly.
As promised...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From b284ba24f771b6ccbf599839bdc813af718b91a1 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 23 Feb 2023
On Thu, Feb 23, 2023 at 10:40:48AM -0800, Nathan Bossart wrote:
> On Tue, Jan 10, 2023 at 03:41:12PM -0800, Nathan Bossart wrote:
>> My vote would be to redefine the existing pg_input_error_message() function
>> to return a record, but I recognize that this would inflate the patch quite
>> a bit
On Tue, Jan 10, 2023 at 03:41:12PM -0800, Nathan Bossart wrote:
> My vote would be to redefine the existing pg_input_error_message() function
> to return a record, but I recognize that this would inflate the patch quite
> a bit due to all the existing uses in the tests. If this is the only
>
On Wed, Jan 04, 2023 at 04:18:59PM -0500, Andrew Dunstan wrote:
> On 2023-01-02 Mo 10:44, Tom Lane wrote:
>> I don't think that just concatenating those strings would make for a
>> pleasant API. More sensible, perhaps, to have a separate function
>> that returns a record. Or we could redefine
On 2023-01-02 Mo 10:44, Tom Lane wrote:
> Andrew Dunstan writes:
>> I've been wondering if it might be a good idea to have a third parameter
>> for pg_input_error_message() which would default to false, but which if
>> true would cause it to emit the detail and hint fields, if any, as well
>> as
Andrew Dunstan writes:
> I've been wondering if it might be a good idea to have a third parameter
> for pg_input_error_message() which would default to false, but which if
> true would cause it to emit the detail and hint fields, if any, as well
> as the message field from the error_data.
I
I've been wondering if it might be a good idea to have a third parameter
for pg_input_error_message() which would default to false, but which if
true would cause it to emit the detail and hint fields, if any, as well
as the message field from the error_data.
Thoughts?
cheers
andrew
--
15 matches
Mail list logo
