agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedBUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors
11+ messages / 5 participants
[nested] [flat]
* BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors
@ 2026-08-19 03:50 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 11+ messages in thread
From: PG Bug reporting form @ 2026-08-19 03:50 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: hackerzheng666@gmail.com
The following bug has been logged on the website:
Bug reference: 19629
Logged by: Zheng Hacker
Email address: hackerzheng666@gmail.com
PostgreSQL version: 19beta3
Operating system: Linux x86_64
Description:
PostgreSQL version: 20devel (commit bdbf662, 2026-08-19)
OS: Linux x86_64
Four ereport(ERROR, ...) calls in src/backend/statistics/stat_utils.c
(function stats_fill_fcinfo_from_arg_pairs) are missing errcode(),
causing user input validation errors to return SQLSTATE XX000
(internal_error) instead of proper error codes.
Reproducers (with \set VERBOSITY verbose):
-- 1. Odd number of variadic args (line 372)
SELECT pg_restore_relation_stats('schemaname', 'stats_import', 'relname');
-- ERROR: XX000: variadic arguments must be name/value pairs
-- LOCATION: stats_fill_fcinfo_from_arg_pairs, stat_utils.c:372
-- 2. NULL argument name (line 387)
SELECT pg_restore_relation_stats(
'schemaname', 'stats_import', 'relname', 'test', NULL, '17'::integer);
-- ERROR: XX000: name at variadic position 5 is null
-- LOCATION: stats_fill_fcinfo_from_arg_pairs, stat_utils.c:387
-- 3. Wrong argument name type (line 391)
SELECT pg_restore_relation_stats(42, 'stats_import', 'relname', 'test');
-- ERROR: XX000: name at variadic position 1 has type integer, expected
type text
-- LOCATION: stats_fill_fcinfo_from_arg_pairs, stat_utils.c:391
A fourth site at line 656 has the same missing errcode pattern.
Suggested fix: add errcode() to each ereport call
(ERRCODE_INVALID_PARAMETER_VALUE,
ERRCODE_NULL_VALUE_NOT_ALLOWED, ERRCODE_DATATYPE_MISMATCH respectively).
Found by automated SQL fuzzing.
Credit: Zheng Wang, Yanjie Zhao, Yiyang Liu
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors
@ 2026-08-19 15:22 Fujii Masao <masao.fujii@gmail.com>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 11+ messages in thread
From: Fujii Masao @ 2026-08-19 15:22 UTC (permalink / raw)
To: hackerzheng666@gmail.com; pgsql-bugs@lists.postgresql.org
On Wed, Aug 19, 2026 at 6:24 PM PG Bug reporting form
<noreply@postgresql.org> wrote:
> Suggested fix: add errcode() to each ereport call
> (ERRCODE_INVALID_PARAMETER_VALUE,
> ERRCODE_NULL_VALUE_NOT_ALLOWED, ERRCODE_DATATYPE_MISMATCH respectively).
Thanks for the report and suggestion!
I agree that these errors should not be reported with SQLSTATE XX000.
Attached is a patch that assigns specific SQLSTATEs to these cases.
The first three use the error codes you suggested. For the fourth case,
"maximum number of statistics slots exceeded", I used
ERRCODE_PROGRAM_LIMIT_EXCEEDED rather than
ERRCODE_INVALID_PARAMETER_VALUE. This is caused by PostgreSQL's fixed
limit on pg_statistic slots, so PROGRAM_LIMIT_EXCEEDED seemed more
appropriate.
I think this should be backpatched to v18, where
pg_restore_relation_stats() and pg_restore_attribute_stats() were
introduced.
Thought?
Regards,
--
Fujii Masao
From 4aff770d6ca0428a30fff2a08630f655e786486e Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Wed, 19 Aug 2026 23:48:13 +0900
Subject: [PATCH v1] Report specific SQLSTATEs for stats restore errors
The pg_restore_*_stats() functions could report SQLSTATE XX000 for
invalid variadic arguments, such as an unmatched name/value pair, a NULL
argument name, or a non-text argument name. Attribute and extended
statistics restores could also report XX000 when the supplied statistics
exceed the number of slots PostgreSQL can store.
These are not internal errors. They result from invalid caller input or
a PostgreSQL implementation limit, but the lack of specific SQLSTATEs
made clients treat them as internal errors.
Assign appropriate SQLSTATEs to these errors so that applications and
tests can classify them correctly.
Backpatch to v18, where pg_restore_relation_stats() and
pg_restore_attribute_stats() were introduced.
---
src/backend/statistics/attribute_stats.c | 3 ++-
src/backend/statistics/stat_utils.c | 11 +++++++----
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/backend/statistics/attribute_stats.c b/src/backend/statistics/attribute_stats.c
index 50f89ff0ac3..8fac52c83c5 100644
--- a/src/backend/statistics/attribute_stats.c
+++ b/src/backend/statistics/attribute_stats.c
@@ -805,7 +805,8 @@ set_stats_slot(Datum *values, bool *nulls, bool *replaces,
if (slotidx >= STATISTIC_NUM_SLOTS)
ereport(ERROR,
- (errmsg("maximum number of statistics slots exceeded: %d",
+ (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
+ errmsg("maximum number of statistics slots exceeded: %d",
slotidx + 1)));
stakind_attnum = Anum_pg_statistic_stakind1 - 1 + slotidx;
diff --git a/src/backend/statistics/stat_utils.c b/src/backend/statistics/stat_utils.c
index 0c139bf43a7..ce1a4dbe1c2 100644
--- a/src/backend/statistics/stat_utils.c
+++ b/src/backend/statistics/stat_utils.c
@@ -312,8 +312,9 @@ stats_fill_fcinfo_from_arg_pairs(FunctionCallInfo pairs_fcinfo,
if (nargs % 2 != 0)
ereport(ERROR,
- errmsg("variadic arguments must be name/value pairs"),
- errhint("Provide an even number of variadic arguments that can be divided into pairs."));
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("variadic arguments must be name/value pairs"),
+ errhint("Provide an even number of variadic arguments that can be divided into pairs.")));
/*
* For each argument name/value pair, find corresponding positional
@@ -327,11 +328,13 @@ stats_fill_fcinfo_from_arg_pairs(FunctionCallInfo pairs_fcinfo,
if (argnulls[i])
ereport(ERROR,
- (errmsg("name at variadic position %d is null", i + 1)));
+ (errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
+ errmsg("name at variadic position %d is null", i + 1)));
if (types[i] != TEXTOID)
ereport(ERROR,
- (errmsg("name at variadic position %d has type %s, expected type %s",
+ (errcode(ERRCODE_DATATYPE_MISMATCH),
+ errmsg("name at variadic position %d has type %s, expected type %s",
i + 1, format_type_be(types[i]),
format_type_be(TEXTOID))));
--
2.55.0
Attachments:
[text/plain] v1-v18-0001-Report-specific-SQLSTATEs-for-stats-restore-error.txt (3.1K, ../../CAHGQGwHZLiLa9iM7NAiugp1B7CumN94=YBeho9t=qKJMnTGwMQ@mail.gmail.com/2-v1-v18-0001-Report-specific-SQLSTATEs-for-stats-restore-error.txt)
download | inline diff:
From 4aff770d6ca0428a30fff2a08630f655e786486e Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Wed, 19 Aug 2026 23:48:13 +0900
Subject: [PATCH v1] Report specific SQLSTATEs for stats restore errors
The pg_restore_*_stats() functions could report SQLSTATE XX000 for
invalid variadic arguments, such as an unmatched name/value pair, a NULL
argument name, or a non-text argument name. Attribute and extended
statistics restores could also report XX000 when the supplied statistics
exceed the number of slots PostgreSQL can store.
These are not internal errors. They result from invalid caller input or
a PostgreSQL implementation limit, but the lack of specific SQLSTATEs
made clients treat them as internal errors.
Assign appropriate SQLSTATEs to these errors so that applications and
tests can classify them correctly.
Backpatch to v18, where pg_restore_relation_stats() and
pg_restore_attribute_stats() were introduced.
---
src/backend/statistics/attribute_stats.c | 3 ++-
src/backend/statistics/stat_utils.c | 11 +++++++----
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/backend/statistics/attribute_stats.c b/src/backend/statistics/attribute_stats.c
index 50f89ff0ac3..8fac52c83c5 100644
--- a/src/backend/statistics/attribute_stats.c
+++ b/src/backend/statistics/attribute_stats.c
@@ -805,7 +805,8 @@ set_stats_slot(Datum *values, bool *nulls, bool *replaces,
if (slotidx >= STATISTIC_NUM_SLOTS)
ereport(ERROR,
- (errmsg("maximum number of statistics slots exceeded: %d",
+ (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
+ errmsg("maximum number of statistics slots exceeded: %d",
slotidx + 1)));
stakind_attnum = Anum_pg_statistic_stakind1 - 1 + slotidx;
diff --git a/src/backend/statistics/stat_utils.c b/src/backend/statistics/stat_utils.c
index 0c139bf43a7..ce1a4dbe1c2 100644
--- a/src/backend/statistics/stat_utils.c
+++ b/src/backend/statistics/stat_utils.c
@@ -312,8 +312,9 @@ stats_fill_fcinfo_from_arg_pairs(FunctionCallInfo pairs_fcinfo,
if (nargs % 2 != 0)
ereport(ERROR,
- errmsg("variadic arguments must be name/value pairs"),
- errhint("Provide an even number of variadic arguments that can be divided into pairs."));
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("variadic arguments must be name/value pairs"),
+ errhint("Provide an even number of variadic arguments that can be divided into pairs.")));
/*
* For each argument name/value pair, find corresponding positional
@@ -327,11 +328,13 @@ stats_fill_fcinfo_from_arg_pairs(FunctionCallInfo pairs_fcinfo,
if (argnulls[i])
ereport(ERROR,
- (errmsg("name at variadic position %d is null", i + 1)));
+ (errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
+ errmsg("name at variadic position %d is null", i + 1)));
if (types[i] != TEXTOID)
ereport(ERROR,
- (errmsg("name at variadic position %d has type %s, expected type %s",
+ (errcode(ERRCODE_DATATYPE_MISMATCH),
+ errmsg("name at variadic position %d has type %s, expected type %s",
i + 1, format_type_be(types[i]),
format_type_be(TEXTOID))));
--
2.55.0
[application/octet-stream] v1-0001-Report-specific-SQLSTATEs-for-stats-restore-error.patch (2.8K, ../../CAHGQGwHZLiLa9iM7NAiugp1B7CumN94=YBeho9t=qKJMnTGwMQ@mail.gmail.com/3-v1-0001-Report-specific-SQLSTATEs-for-stats-restore-error.patch)
download | inline diff:
From 489778d7056a5fd3fe1609dbe74533a44a91eab4 Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Wed, 19 Aug 2026 23:23:22 +0900
Subject: [PATCH v1] Report specific SQLSTATEs for stats restore errors
The pg_restore_*_stats() functions could report SQLSTATE XX000 for
invalid variadic arguments, such as an unmatched name/value pair, a NULL
argument name, or a non-text argument name. Attribute and extended
statistics restores could also report XX000 when the supplied statistics
exceed the number of slots PostgreSQL can store.
These are not internal errors. They result from invalid caller input or
a PostgreSQL implementation limit, but the lack of specific SQLSTATEs
made clients treat them as internal errors.
Assign appropriate SQLSTATEs to these errors so that applications and
tests can classify them correctly.
Backpatch to v18, where pg_restore_relation_stats() and
pg_restore_attribute_stats() were introduced.
---
src/backend/statistics/stat_utils.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/backend/statistics/stat_utils.c b/src/backend/statistics/stat_utils.c
index 5ff37ef4cf8..f4ff9ab9b20 100644
--- a/src/backend/statistics/stat_utils.c
+++ b/src/backend/statistics/stat_utils.c
@@ -370,8 +370,9 @@ stats_fill_fcinfo_from_arg_pairs(FunctionCallInfo pairs_fcinfo,
if (nargs % 2 != 0)
ereport(ERROR,
- errmsg("variadic arguments must be name/value pairs"),
- errhint("Provide an even number of variadic arguments that can be divided into pairs."));
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("variadic arguments must be name/value pairs"),
+ errhint("Provide an even number of variadic arguments that can be divided into pairs.")));
/*
* For each argument name/value pair, find corresponding positional
@@ -385,11 +386,13 @@ stats_fill_fcinfo_from_arg_pairs(FunctionCallInfo pairs_fcinfo,
if (argnulls[i])
ereport(ERROR,
- (errmsg("name at variadic position %d is null", i + 1)));
+ (errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
+ errmsg("name at variadic position %d is null", i + 1)));
if (types[i] != TEXTOID)
ereport(ERROR,
- (errmsg("name at variadic position %d has type %s, expected type %s",
+ (errcode(ERRCODE_DATATYPE_MISMATCH),
+ errmsg("name at variadic position %d has type %s, expected type %s",
i + 1, format_type_be(types[i]),
format_type_be(TEXTOID))));
@@ -654,7 +657,8 @@ statatt_set_slot(Datum *values, bool *nulls, bool *replaces,
if (slotidx >= STATISTIC_NUM_SLOTS)
ereport(ERROR,
- (errmsg("maximum number of statistics slots exceeded: %d",
+ (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
+ errmsg("maximum number of statistics slots exceeded: %d",
slotidx + 1)));
stakind_attnum = Anum_pg_statistic_stakind1 - 1 + slotidx;
--
2.55.0
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors
@ 2026-08-19 16:12 Ayush Tiwari <ayushtiwari.slg01@gmail.com>
parent: Fujii Masao <masao.fujii@gmail.com>
0 siblings, 2 replies; 11+ messages in thread
From: Ayush Tiwari @ 2026-08-19 16:12 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@gmail.com>; +Cc: hackerzheng666@gmail.com; pgsql-bugs@lists.postgresql.org
Hi,
On Wed, 19 Aug 2026 at 20:52, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Wed, Aug 19, 2026 at 6:24 PM PG Bug reporting form
> <noreply@postgresql.org> wrote:
> > Suggested fix: add errcode() to each ereport call
> > (ERRCODE_INVALID_PARAMETER_VALUE,
> > ERRCODE_NULL_VALUE_NOT_ALLOWED, ERRCODE_DATATYPE_MISMATCH
> respectively).
>
> Thanks for the report and suggestion!
>
> I agree that these errors should not be reported with SQLSTATE XX000.
> Attached is a patch that assigns specific SQLSTATEs to these cases.
>
> The first three use the error codes you suggested. For the fourth case,
> "maximum number of statistics slots exceeded", I used
> ERRCODE_PROGRAM_LIMIT_EXCEEDED rather than
> ERRCODE_INVALID_PARAMETER_VALUE. This is caused by PostgreSQL's fixed
> limit on pg_statistic slots, so PROGRAM_LIMIT_EXCEEDED seemed more
> appropriate.
>
> I think this should be backpatched to v18, where
> pg_restore_relation_stats() and pg_restore_attribute_stats() were
> introduced.
>
> Thought?
>
Thanks for the patch, Fujii-san!
I had posted a patch for all the three related bugs at [0]
Found some more places where the issue exists and added
there. Maybe you can incorporate those too in your patch?
Regards,
Ayush
[0]
https://www.postgresql.org/message-id/CAJTYsWWpwHsvzKp0JPvGbWttXrOafMCtmGBBQs6bhCKn88fgug%40mail.gma...
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors
@ 2026-08-20 09:06 Ayush Tiwari <ayushtiwari.slg01@gmail.com>
parent: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
1 sibling, 0 replies; 11+ messages in thread
From: Ayush Tiwari @ 2026-08-20 09:06 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@gmail.com>; +Cc: hackerzheng666@gmail.com; pgsql-bugs@lists.postgresql.org
Hi,
On Wed, 19 Aug 2026 at 21:42, Ayush Tiwari <ayushtiwari.slg01@gmail.com>
wrote:
> Hi,
>
> On Wed, 19 Aug 2026 at 20:52, Fujii Masao <masao.fujii@gmail.com> wrote:
>
>> On Wed, Aug 19, 2026 at 6:24 PM PG Bug reporting form
>> <noreply@postgresql.org> wrote:
>> > Suggested fix: add errcode() to each ereport call
>> > (ERRCODE_INVALID_PARAMETER_VALUE,
>> > ERRCODE_NULL_VALUE_NOT_ALLOWED, ERRCODE_DATATYPE_MISMATCH
>> respectively).
>>
>> Thanks for the report and suggestion!
>>
>> I agree that these errors should not be reported with SQLSTATE XX000.
>> Attached is a patch that assigns specific SQLSTATEs to these cases.
>>
>> The first three use the error codes you suggested. For the fourth case,
>> "maximum number of statistics slots exceeded", I used
>> ERRCODE_PROGRAM_LIMIT_EXCEEDED rather than
>> ERRCODE_INVALID_PARAMETER_VALUE. This is caused by PostgreSQL's fixed
>> limit on pg_statistic slots, so PROGRAM_LIMIT_EXCEEDED seemed more
>> appropriate.
>>
>> I think this should be backpatched to v18, where
>> pg_restore_relation_stats() and pg_restore_attribute_stats() were
>> introduced.
>>
>> Thought?
>>
>
> Thanks for the patch, Fujii-san!
>
> I had posted a patch for all the three related bugs at [0]
>
> Found some more places where the issue exists and added
> there. Maybe you can incorporate those too in your patch?
>
Updating link for [0] to the all-in [19629-19632 thread]
Regards,
Ayush
[0]
https://www.postgresql.org/message-id/CAJTYsWUuL1cvBrameN2r-n6k8Ju8nqymJVeamaf%2B1FDneTxRLw%40mail.g...
<https://www.postgresql.org/message-id/CAJTYsWUuL1cvBrameN2r-n6k8Ju8nqymJVeamaf%2B1FDneTxRLw%40mail.g...;
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors
@ 2026-08-20 22:30 Michael Paquier <michael@paquier.xyz>
parent: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
1 sibling, 2 replies; 11+ messages in thread
From: Michael Paquier @ 2026-08-20 22:30 UTC (permalink / raw)
To: Ayush Tiwari <ayushtiwari.slg01@gmail.com>; +Cc: Fujii Masao <masao.fujii@gmail.com>; hackerzheng666@gmail.com; pgsql-bugs@lists.postgresql.org
On Wed, Aug 19, 2026 at 09:42:18PM +0530, Ayush Tiwari wrote:
> On Wed, 19 Aug 2026 at 20:52, Fujii Masao <masao.fujii@gmail.com> wrote:
>> I think this should be backpatched to v18, where
>> pg_restore_relation_stats() and pg_restore_attribute_stats() were
>> introduced.
>>
>> Thought?
Adding an errcode() is a life improvement thing. So, while I agree
that the proposed patch is an improvement, I don't see a strong need
for a backpatch. Feel free to override this argument as you feel, of
course.
Just a note: I've tried to be careful with assigning errcodes for all
the new error paths of extended_stats_funcs.c added in v19 that can be
reached by SQL. If there are holes in there, please let me know.
> Found some more places where the issue exists and added
> there. Maybe you can incorporate those too in your patch?
I'd suggest to keep things isolated in their own fashion, as they
address different areas with slightly different user-changes changes
(okay, not much).
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../aoeAHXVBs8S5mk-c@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors
@ 2026-08-21 05:18 Ayush Tiwari <ayushtiwari.slg01@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 0 replies; 11+ messages in thread
From: Ayush Tiwari @ 2026-08-21 05:18 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Fujii Masao <masao.fujii@gmail.com>; hackerzheng666@gmail.com; pgsql-bugs@lists.postgresql.org
Hi,
On Fri, 21 Aug 2026 at 04:00, Michael Paquier <michael@paquier.xyz> wrote:
> On Wed, Aug 19, 2026 at 09:42:18PM +0530, Ayush Tiwari wrote:
> > On Wed, 19 Aug 2026 at 20:52, Fujii Masao <masao.fujii@gmail.com> wrote:
> >> I think this should be backpatched to v18, where
> >> pg_restore_relation_stats() and pg_restore_attribute_stats() were
> >> introduced.
> >>
> >> Thought?
>
> Adding an errcode() is a life improvement thing. So, while I agree
> that the proposed patch is an improvement, I don't see a strong need
> for a backpatch. Feel free to override this argument as you feel, of
> course.
>
FWIW I think it's more of a bug too rather than just improvement
some of the applications depend on the errcode PG emits
to give end results.
> Just a note: I've tried to be careful with assigning errcodes for all
> the new error paths of extended_stats_funcs.c added in v19 that can be
> reached by SQL. If there are holes in there, please let me know.
>
> > Found some more places where the issue exists and added
> > there. Maybe you can incorporate those too in your patch?
>
> I'd suggest to keep things isolated in their own fashion, as they
> address different areas with slightly different user-changes changes
> (okay, not much).
>
Ahh atleast for 19629-31 I thought they shared the exact root cause
of not specified errcodes, and there were few more in the tree, but
I'm fine with the splitting part if needed.
Regards,
Ayush
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors
@ 2026-08-21 08:41 Fujii Masao <masao.fujii@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 2 replies; 11+ messages in thread
From: Fujii Masao @ 2026-08-21 08:41 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Ayush Tiwari <ayushtiwari.slg01@gmail.com>; hackerzheng666@gmail.com; pgsql-bugs@lists.postgresql.org
On Fri, Aug 21, 2026 at 7:30 AM Michael Paquier <michael@paquier.xyz> wrote:
> Adding an errcode() is a life improvement thing. So, while I agree
> that the proposed patch is an improvement, I don't see a strong need
> for a backpatch. Feel free to override this argument as you feel, of
> course.
I understand your point, but I'm inclined to backpatch this to v18.
These are input-validation errors that are directly reachable from SQL,
and the SQLSTATE is exposed to applications. Since applications commonly
branch on SQLSTATE, reporting XX000 makes these errors look like internal
errors rather than invalid input. That seems more like a bug than
a cosmetic improvement to me.
Also, these functions were introduced in v18, so the risk of breaking
existing applications that depend on the current XX000 behavior should
be low. For these reasons, I think backpatching to v18 is preferable here.
Thoughts?
But, on the other hand, if we want to avoid breaking existing
applications that depend on the current XX000 behavior, backpatching
to v19 might be a reasonable alternative.
> I'd suggest to keep things isolated in their own fashion, as they
> address different areas with slightly different user-changes changes
> (okay, not much).
+1
Regards,
--
Fujii Masao
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors
@ 2026-08-24 12:00 Alexander Lakhin <exclusion@gmail.com>
parent: Fujii Masao <masao.fujii@gmail.com>
1 sibling, 1 reply; 11+ messages in thread
From: Alexander Lakhin @ 2026-08-24 12:00 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@gmail.com>; Michael Paquier <michael@paquier.xyz>; +Cc: Ayush Tiwari <ayushtiwari.slg01@gmail.com>; hackerzheng666@gmail.com; pgsql-bugs@lists.postgresql.org
Hello,
21.08.2026 11:41, Fujii Masao wrote:
> On Fri, Aug 21, 2026 at 7:30 AM Michael Paquier <michael@paquier.xyz> wrote:
>> Adding an errcode() is a life improvement thing. So, while I agree
>> that the proposed patch is an improvement, I don't see a strong need
>> for a backpatch. Feel free to override this argument as you feel, of
>> course.
> I understand your point, but I'm inclined to backpatch this to v18.
>
> These are input-validation errors that are directly reachable from SQL,
> and the SQLSTATE is exposed to applications. Since applications commonly
> branch on SQLSTATE, reporting XX000 makes these errors look like internal
> errors rather than invalid input. That seems more like a bug than
> a cosmetic improvement to me.
>
>> I'd suggest to keep things isolated in their own fashion, as they
>> address different areas with slightly different user-changes changes
>> (okay, not much).
FWIW, I have my own collection of XX000 errors that can be reached by
users. I see there are distinct bug reports following this one, but I
guess, it won't be convenient to process dozens of such reports (if I
add mine). Maybe it would make sense to create a wiki page to
enumerate all these legally reachable internal errors (probably some of
them would stay as-is)...
What do you think?
Just a couple of examples to be concrete:
do $$ #print_strict_params XXX $$;
ERROR: XX000: unrecognized print_strict_params option xxx
select pg_catalog.range_in('', 23, 0);
ERROR: XX000: type 23 is not a range type
Best regards,
Alexander
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors
@ 2026-08-24 23:49 Michael Paquier <michael@paquier.xyz>
parent: Alexander Lakhin <exclusion@gmail.com>
0 siblings, 0 replies; 11+ messages in thread
From: Michael Paquier @ 2026-08-24 23:49 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: Fujii Masao <masao.fujii@gmail.com>; Ayush Tiwari <ayushtiwari.slg01@gmail.com>; hackerzheng666@gmail.com; pgsql-bugs@lists.postgresql.org
On Mon, Aug 24, 2026 at 03:00:01PM +0300, Alexander Lakhin wrote:
> FWIW, I have my own collection of XX000 errors that can be reached by
> users. I see there are distinct bug reports following this one, but I
> guess, it won't be convenient to process dozens of such reports (if I
> add mine). Maybe it would make sense to create a wiki page to
> enumerate all these legally reachable internal errors (probably some of
> them would stay as-is)...
>
> What do you think?
You have automated their detection, don't you? If you have dozens of
them piled up, I would not mind if you send them in a single batch on
a new thread..
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../aozYob22-UJ8CWzk@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors
@ 2026-08-25 05:14 Fujii Masao <masao.fujii@gmail.com>
parent: Fujii Masao <masao.fujii@gmail.com>
1 sibling, 1 reply; 11+ messages in thread
From: Fujii Masao @ 2026-08-25 05:14 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Ayush Tiwari <ayushtiwari.slg01@gmail.com>; hackerzheng666@gmail.com; pgsql-bugs@lists.postgresql.org
On Fri, Aug 21, 2026 at 5:41 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> I understand your point, but I'm inclined to backpatch this to v18.
>
> These are input-validation errors that are directly reachable from SQL,
> and the SQLSTATE is exposed to applications. Since applications commonly
> branch on SQLSTATE, reporting XX000 makes these errors look like internal
> errors rather than invalid input. That seems more like a bug than
> a cosmetic improvement to me.
>
> Also, these functions were introduced in v18, so the risk of breaking
> existing applications that depend on the current XX000 behavior should
> be low. For these reasons, I think backpatching to v18 is preferable here.
> Thoughts?
>
> But, on the other hand, if we want to avoid breaking existing
> applications that depend on the current XX000 behavior, backpatching
> to v19 might be a reasonable alternative.
I found a similar precedent in commit 89e80b032975. It also changed
user-visible SQLSTATEs from XX000 to more appropriate error codes,
but was backpatched only to v9.5, which had not been released yet
at the time. The commit message says:
Back-patch to 9.5, but no further; changing ERRCODE assignments in
stable branches doesn't seem like a good idea.
Following that, I am now inclined to backpatch this only to v19, and
not to v18.
Regards,
--
Fujii Masao
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors
@ 2026-08-27 14:45 Fujii Masao <masao.fujii@gmail.com>
parent: Fujii Masao <masao.fujii@gmail.com>
0 siblings, 0 replies; 11+ messages in thread
From: Fujii Masao @ 2026-08-27 14:45 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Ayush Tiwari <ayushtiwari.slg01@gmail.com>; hackerzheng666@gmail.com; pgsql-bugs@lists.postgresql.org
On Tue, Aug 25, 2026 at 2:14 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> I found a similar precedent in commit 89e80b032975. It also changed
> user-visible SQLSTATEs from XX000 to more appropriate error codes,
> but was backpatched only to v9.5, which had not been released yet
> at the time. The commit message says:
>
> Back-patch to 9.5, but no further; changing ERRCODE assignments in
> stable branches doesn't seem like a good idea.
>
> Following that, I am now inclined to backpatch this only to v19, and
> not to v18.
I've pushed the patch and backpatched it to v19. Thanks!
Regards,
--
Fujii Masao
^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2026-08-27 14:45 UTC | newest]
Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-08-19 03:50 BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors PG Bug reporting form <noreply@postgresql.org>
2026-08-19 15:22 ` Fujii Masao <masao.fujii@gmail.com>
2026-08-19 16:12 ` Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-08-20 09:06 ` Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-08-20 22:30 ` Michael Paquier <michael@paquier.xyz>
2026-08-21 05:18 ` Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-08-21 08:41 ` Fujii Masao <masao.fujii@gmail.com>
2026-08-24 12:00 ` Alexander Lakhin <exclusion@gmail.com>
2026-08-24 23:49 ` Michael Paquier <michael@paquier.xyz>
2026-08-25 05:14 ` Fujii Masao <masao.fujii@gmail.com>
2026-08-27 14:45 ` Fujii Masao <masao.fujii@gmail.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox