pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedAssert failure in base_yyparse
10+ messages / 3 participants
[nested] [flat]
Commits from this thread:
2025-05-15 fe29b2a1da 2f48b4f075 d3716d4b13 666103090f Fix Assert failure in XMLTABLE parser
* Assert failure in base_yyparse
@ 2025-03-28 07:39 Евгений Горбанев <gorbanyoves@basealt.ru>
2025-03-28 09:05 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Евгений Горбанев @ 2025-03-28 07:39 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org
Hello.
Got an assert failure when fuzzing the raw_parser function.
The query to reproduce:
SELECT xmltable.* FROM xmltest2, LATERAL xmltable('/d/r' PASSING x
COLUMNS a int PATH '' || lower(_path) is_not_null|| 'c');
If I understand correctly, is_not_null is considered as a valid keyword
in xmltable, but it gets the type T_A_Expr.
Postgres output:
$ ./postgres -D data
2025-03-28 12:19:19.945 +06 [53058] LOG: starting PostgreSQL 18devel on
x86_64-pc-linux-gnu, compiled by x86_64-alt-linux-gcc (GCC) 10.3.1
20210703 (ALT Sisyphus 10.3.1-alt2), 64-bit
2025-03-28 12:19:19.946 +06 [53058] LOG: listening on IPv4 address
"127.0.0.1", port 5432
2025-03-28 12:19:20.032 +06 [53058] LOG: listening on Unix socket
"/tmp/.s.PGSQL.5432"
2025-03-28 12:19:20.281 +06 [53064] LOG: database system was shut down
at 2025-03-28 12:18:37 +06
2025-03-28 12:19:20.342 +06 [53058] LOG: database system is ready to
accept connections
TRAP: failed Assert("ptr == NULL || nodeTag(ptr) == type"), File:
"../../../src/include/nodes/nodes.h", Line: 177, PID: 53069
postgres: user postgres 127.0.0.1(56762)
idle(ExceptionalCondition+0x141)[0x5561768c0fb6]
postgres: user postgres 127.0.0.1(56762) idle(+0x585784)[0x556175e03784]
postgres: user postgres 127.0.0.1(56762)
idle(base_yyparse+0x30578)[0x556175e33f83]
postgres: user postgres 127.0.0.1(56762)
idle(raw_parser+0xf5)[0x556175ec0f47]
postgres: user postgres 127.0.0.1(56762)
idle(pg_parse_query+0x63)[0x556176550a67]
postgres: user postgres 127.0.0.1(56762) idle(+0xcd3bcf)[0x556176551bcf]
postgres: user postgres 127.0.0.1(56762)
idle(PostgresMain+0x14ef)[0x55617655ca54]
postgres: user postgres 127.0.0.1(56762) idle(+0xccc207)[0x55617654a207]
postgres: user postgres 127.0.0.1(56762)
idle(postmaster_child_launch+0x2ae)[0x5561763ad6e8]
postgres: user postgres 127.0.0.1(56762) idle(+0xb3bc75)[0x5561763b9c75]
postgres: user postgres 127.0.0.1(56762) idle(+0xb3686b)[0x5561763b486b]
postgres: user postgres 127.0.0.1(56762)
idle(PostmasterMain+0x288f)[0x5561763b3bdb]
postgres: user postgres 127.0.0.1(56762) idle(main+0x5dc)[0x55617616dfbd]
/lib64/libc.so.6(__libc_start_main+0xcd)[0x7f36ef05fefd]
postgres: user postgres 127.0.0.1(56762) idle(_start+0x2a)[0x556175b4a39a]
2025-03-28 12:19:24.020 +06 [53058] LOG: client backend (PID 53069) was
terminated by signal 6: Aborted
2025-03-28 12:19:24.020 +06 [53058] DETAIL: Failed process was running:
SELECT xmltable.* FROM xmltest2, LATERAL xmltable('/d/r' PASSING x
COLUMNS a int PATH '' || lower(_path) is_not_null|| 'c');
2025-03-28 12:19:24.020 +06 [53058] LOG: terminating any other active
server processes
2025-03-28 12:19:24.021 +06 [53058] LOG: all server processes
terminated; reinitializing
2025-03-28 12:19:24.220 +06 [53080] LOG: database system was
interrupted; last known up at 2025-03-28 12:19:20 +06
2025-03-28 12:19:28.268 +06 [53080] LOG: database system was not
properly shut down; automatic recovery in progress
2025-03-28 12:19:28.296 +06 [53080] LOG: invalid record length at
0/17864A0: expected at least 24, got 0
2025-03-28 12:19:28.296 +06 [53080] LOG: redo is not required
2025-03-28 12:19:28.414 +06 [53081] LOG: checkpoint starting:
end-of-recovery immediate wait
2025-03-28 12:19:28.561 +06 [53081] LOG: checkpoint complete: wrote 0
buffers (0.0%), wrote 3 SLRU buffers; 0 WAL file(s) added, 0 removed, 0
recycled; write=0.014 s, sync=0.004 s, total=0.183 s; sync files=2,
longest=0.002 s, average=0.002 s; distance=0 kB, estimate=0 kB;
lsn=0/17864A0, redo lsn=0/17864A0
2025-03-28 12:19:28.618 +06 [53058] LOG: database system is ready to
accept connections
^C2025-03-28 12:19:30.116 +06 [53058] LOG: received fast shutdown request
2025-03-28 12:19:30.259 +06 [53058] LOG: aborting any active transactions
2025-03-28 12:19:30.313 +06 [53081] LOG: shutting down
2025-03-28 12:19:30.464 +06 [53081] LOG: checkpoint starting: shutdown
immediate
2025-03-28 12:19:30.515 +06 [53081] LOG: checkpoint complete: wrote 0
buffers (0.0%), wrote 0 SLRU buffers; 0 WAL file(s) added, 0 removed, 0
recycled; write=0.001 s, sync=0.001 s, total=0.202 s; sync files=0,
longest=0.000 s, average=0.000 s; distance=0 kB, estimate=0 kB;
lsn=0/1786518, redo lsn=0/1786518
2025-03-28 12:19:30.665 +06 [53058] LOG: database system is shut down
Prepared a patch to fix it, but there may be a better solution.
Attachments:
0001-Fix-usage-of-is_not_null-in-xmltable.patch (text/x-patch, 1.1K) download
From e54dbe190a0e5a0bbbadd07af8aa6b24433ad02a Mon Sep 17 00:00:00 2001
From: Evgeniy Gorbanev <gorbanyoves@basealt.ru>
Date: Fri, 28 Mar 2025 13:07:07 +0600
Subject: [PATCH] Fix usage of is_not_null in xmltable
is_not_null is considered as a valid keyword in xmltable, but it gets the type T_A_Expr
---
src/backend/parser/gram.y | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 0fc502a3a40..e3f22cb8b77 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -14232,6 +14232,11 @@ xmltable_column_el:
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("conflicting or redundant NULL / NOT NULL declarations for column \"%s\"", fc->colname),
parser_errposition(defel->location)));
+ if (defel->arg->type != T_Boolean)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("syntax error at or near \"%s\"", defel->defname),
+ parser_errposition(defel->location)));
fc->is_not_null = boolVal(defel->arg);
nullability_seen = true;
}
--
2.42.2
* Re: Assert failure in base_yyparse
2025-03-28 07:39 Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
@ 2025-03-28 09:05 ` Richard Guo <guofenglinux@gmail.com>
2025-03-28 09:34 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Richard Guo @ 2025-03-28 09:05 UTC (permalink / raw)
To: Евгений Горбанев <gorbanyoves@basealt.ru>; +Cc: pgsql-hackers@lists.postgresql.org
On Fri, Mar 28, 2025 at 4:40 PM Евгений Горбанев <gorbanyoves@basealt.ru> wrote:
> Got an assert failure when fuzzing the raw_parser function.
> The query to reproduce:
> SELECT xmltable.* FROM xmltest2, LATERAL xmltable('/d/r' PASSING x
> COLUMNS a int PATH '' || lower(_path) is_not_null|| 'c');
>
> If I understand correctly, is_not_null is considered as a valid keyword
> in xmltable, but it gets the type T_A_Expr.
> Prepared a patch to fix it, but there may be a better solution.
Nice catch. Yeah, is_not_null is a valid column option in xmltable.
In you example, the value of the is_not_null option is "|| 'c'", which
is interpreted as an A_Expr.
I wonder if the value's type should be checked earlier, rather than at
the last minute.
Also, I think IsA is a better choice for checking the node type.
Thanks
Richard
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Assert failure in base_yyparse
2025-03-28 07:39 Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-03-28 09:05 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
@ 2025-03-28 09:34 ` Richard Guo <guofenglinux@gmail.com>
2025-03-28 10:12 ` Re: Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
0 siblings, 1 reply; 10+ messages in thread
From: Richard Guo @ 2025-03-28 09:34 UTC (permalink / raw)
To: Евгений Горбанев <gorbanyoves@basealt.ru>; +Cc: pgsql-hackers@lists.postgresql.org
On Fri, Mar 28, 2025 at 6:05 PM Richard Guo <guofenglinux@gmail.com> wrote:
> Nice catch. Yeah, is_not_null is a valid column option in xmltable.
> In you example, the value of the is_not_null option is "|| 'c'", which
> is interpreted as an A_Expr.
>
> I wonder if the value's type should be checked earlier, rather than at
> the last minute.
Hmm, I wonder if we should allow the use of the 'is_not_null' keyword
in xmltable. According to the doc, it seems that users should declare
NULL or NOT NULL for a column by specifying [NOT NULL | NULL] for the
column.
Thanks
Richard
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Assert failure in base_yyparse
2025-03-28 07:39 Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-03-28 09:05 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-03-28 09:34 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
@ 2025-03-28 10:12 ` Евгений Горбанев <gorbanyoves@basealt.ru>
2025-04-14 08:45 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Евгений Горбанев @ 2025-03-28 10:12 UTC (permalink / raw)
To: Richard Guo <guofenglinux@gmail.com>; +Cc: pgsql-hackers@lists.postgresql.org
> Also, I think IsA is a better choice for checking the node type.
Agree, IsA is better. Fixed in the patch.
> On Fri, Mar 28, 2025 at 6:05 PM Richard Guo <guofenglinux@gmail.com> wrote:
> Hmm, I wonder if we should allow the use of the 'is_not_null' keyword
> in xmltable. According to the doc, it seems that users should declare
> NULL or NOT NULL for a column by specifying [NOT NULL | NULL] for the
> column.
>
> Thanks
> Richard
If you replace is_not_null with NOT NULL in the query, everything works
correctly.
It seems that is_not_null is an incorrect keyword and it should not be
used, but I don't understand how it gets here.
Best regards,
Evgeniy
Attachments:
0001-Fix-usage-of-is_not_null-in-xmltable.patch (text/x-patch, 1.1K) download
From de66a7ac776b827cba748e0a358b6d3911790e23 Mon Sep 17 00:00:00 2001
From: Evgeniy Gorbanev <gorbanyoves@basealt.ru>
Date: Fri, 28 Mar 2025 15:54:37 +0600
Subject: [PATCH] Fix usage of is_not_null in xmltable
is_not_null is considered as a valid keyword in xmltable, but it gets the type T_A_Expr
---
src/backend/parser/gram.y | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 0fc502a3a40..84762c2511b 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -14232,6 +14232,11 @@ xmltable_column_el:
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("conflicting or redundant NULL / NOT NULL declarations for column \"%s\"", fc->colname),
parser_errposition(defel->location)));
+ if (!IsA(defel->arg, Boolean))
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("syntax error at or near \"%s\"", defel->defname),
+ parser_errposition(defel->location)));
fc->is_not_null = boolVal(defel->arg);
nullability_seen = true;
}
--
2.42.2
* Re: Assert failure in base_yyparse
2025-03-28 07:39 Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-03-28 09:05 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-03-28 09:34 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-03-28 10:12 ` Re: Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
@ 2025-04-14 08:45 ` Richard Guo <guofenglinux@gmail.com>
2025-05-09 05:54 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-05-09 09:44 ` Re: Assert failure in base_yyparse Alvaro Herrera <alvherre@kurilemu.de>
0 siblings, 2 replies; 10+ messages in thread
From: Richard Guo @ 2025-04-14 08:45 UTC (permalink / raw)
To: Евгений Горбанев <gorbanyoves@basealt.ru>; +Cc: pgsql-hackers@lists.postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
On Fri, Mar 28, 2025 at 7:12 PM Евгений Горбанев <gorbanyoves@basealt.ru> wrote:
> If you replace is_not_null with NOT NULL in the query, everything works
> correctly.
> It seems that is_not_null is an incorrect keyword and it should not be
> used, but I don't understand how it gets here.
It seems what happens is that internally in gram.y (~line 14274), the
DefElem for the not-null option is assigned the name "is_not_null".
As a result, this allows users to explicitly use "is_not_null" as the
option name. However, the value provided for the is_not_null option
in this way might not be a Boolean as expected, which triggers the
assertion.
I kind of doubt we should allow the use of the "is_not_null" keyword
in the xmltable function.
Hi Álvaro, what do you think about this?
Thanks
Richard
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Assert failure in base_yyparse
2025-03-28 07:39 Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-03-28 09:05 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-03-28 09:34 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-03-28 10:12 ` Re: Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-04-14 08:45 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
@ 2025-05-09 05:54 ` Richard Guo <guofenglinux@gmail.com>
1 sibling, 0 replies; 10+ messages in thread
From: Richard Guo @ 2025-05-09 05:54 UTC (permalink / raw)
To: Евгений Горбанев <gorbanyoves@basealt.ru>; +Cc: pgsql-hackers@lists.postgresql.org, Álvaro Herrera <alvherre@kurilemu.de>
On Mon, Apr 14, 2025 at 5:45 PM Richard Guo <guofenglinux@gmail.com> wrote:
> It seems what happens is that internally in gram.y (~line 14274), the
> DefElem for the not-null option is assigned the name "is_not_null".
> As a result, this allows users to explicitly use "is_not_null" as the
> option name. However, the value provided for the is_not_null option
> in this way might not be a Boolean as expected, which triggers the
> assertion.
>
> I kind of doubt we should allow the use of the "is_not_null" keyword
> in the xmltable function.
>
> Hi Álvaro, what do you think about this?
Just realized Álvaro has switched to a new email address — re-cc'ing.
Thanks
Richard
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Assert failure in base_yyparse
2025-03-28 07:39 Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-03-28 09:05 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-03-28 09:34 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-03-28 10:12 ` Re: Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-04-14 08:45 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
@ 2025-05-09 09:44 ` Alvaro Herrera <alvherre@kurilemu.de>
2025-05-14 07:06 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
1 sibling, 1 reply; 10+ messages in thread
From: Alvaro Herrera @ 2025-05-09 09:44 UTC (permalink / raw)
To: Richard Guo <guofenglinux@gmail.com>; +Cc: Евгений Горбанев <gorbanyoves@basealt.ru>; pgsql-hackers@lists.postgresql.org
On 2025-Apr-14, Richard Guo wrote:
> It seems what happens is that internally in gram.y (~line 14274), the
> DefElem for the not-null option is assigned the name "is_not_null".
> As a result, this allows users to explicitly use "is_not_null" as the
> option name. However, the value provided for the is_not_null option
> in this way might not be a Boolean as expected, which triggers the
> assertion.
>
> I kind of doubt we should allow the use of the "is_not_null" keyword
> in the xmltable function.
>
> Hi Álvaro, what do you think about this?
Hello Richard, sorry that I failed to notice this earlier.
I agree that blocking the index from using the option name that xmltable
parsing uses internally is okay. Maybe we can rename it to something
like "__pg__is_not_null" or something like that, which would reduce the
chances of troubling people; the existing name sounds too much like a
valid name that users could want to use.
Also, maybe rather than just "syntax error" we could say something like
"option name XYZ cannot be used in XMLTABLE".
I wonder if we have any other names used by the parser that can cause
this kind of problem. In a quick look through gram.y I didn't find any
other place that would fabricate a name and also accept arbitrary
user-specified names to use, so this seems to be the only place affected
by this particular bug.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Assert failure in base_yyparse
2025-03-28 07:39 Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-03-28 09:05 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-03-28 09:34 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-03-28 10:12 ` Re: Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-04-14 08:45 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-05-09 09:44 ` Re: Assert failure in base_yyparse Alvaro Herrera <alvherre@kurilemu.de>
@ 2025-05-14 07:06 ` Richard Guo <guofenglinux@gmail.com>
2025-05-14 16:20 ` Re: Assert failure in base_yyparse Alvaro Herrera <alvherre@kurilemu.de>
0 siblings, 1 reply; 10+ messages in thread
From: Richard Guo @ 2025-05-14 07:06 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@kurilemu.de>; +Cc: Евгений Горбанев <gorbanyoves@basealt.ru>; pgsql-hackers@lists.postgresql.org
On Fri, May 9, 2025 at 6:50 PM Alvaro Herrera <alvherre@kurilemu.de> wrote:
> I agree that blocking the index from using the option name that xmltable
> parsing uses internally is okay. Maybe we can rename it to something
> like "__pg__is_not_null" or something like that, which would reduce the
> chances of troubling people; the existing name sounds too much like a
> valid name that users could want to use.
>
> Also, maybe rather than just "syntax error" we could say something like
> "option name XYZ cannot be used in XMLTABLE".
Agreed on both points.
Evgeniy's patch checks the type of the option argument at the last
moment and raises an error if it's not Boolean. I think it might be
better to check whether the user-supplied name collides with the
internally reserved name earlier in the process. According to the
doc, users should specify column nullability using [NOT NULL | NULL]
in the column definition, rather than explicitly setting an
"is_not_null" option.
Attached is a patch that implements this. It also renames the
internally used option name and updates the error message.
> I wonder if we have any other names used by the parser that can cause
> this kind of problem. In a quick look through gram.y I didn't find any
> other place that would fabricate a name and also accept arbitrary
> user-specified names to use, so this seems to be the only place affected
> by this particular bug.
Yeah. Thanks for checking.
Thanks
Richard
Attachments:
v1-0001-Fix-Assert-failure-in-XMLTABLE-parser.patch (application/octet-stream, 5.7K) download
From 312ea93bfac03db7b1e5e72e173f272851ca57d0 Mon Sep 17 00:00:00 2001
From: Richard Guo <guofenglinux@gmail.com>
Date: Tue, 13 May 2025 17:56:55 +0900
Subject: [PATCH v1] Fix Assert failure in XMLTABLE parser
In an XMLTABLE expression, columns can be marked NOT NULL, and the
parser internally fabricates an option named "is_not_null" to
represent this. However, the parser also allows users to specify
arbitrary option names. This creates a conflict: a user can
explicitly use "is_not_null" as an option name and assign it a
non-Boolean value, which violates internal assumptions and triggers an
assertion failure.
To fix, this patch checks whether a user-supplied name collides with
the internally reserved option name and raises an error if so.
Additionally, the internal name is renamed to "__pg__is_not_null" to
further reduce the risk of collision with user-defined names.
---
src/backend/parser/gram.y | 15 +++++++++++----
src/test/regress/expected/xml.out | 4 ++++
src/test/regress/expected/xml_1.out | 4 ++++
src/test/regress/expected/xml_2.out | 4 ++++
src/test/regress/sql/xml.sql | 2 ++
5 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 3c4268b271a..0b5652071d1 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -14230,7 +14230,7 @@ xmltable_column_el:
parser_errposition(defel->location)));
fc->colexpr = defel->arg;
}
- else if (strcmp(defel->defname, "is_not_null") == 0)
+ else if (strcmp(defel->defname, "__pg__is_not_null") == 0)
{
if (nullability_seen)
ereport(ERROR,
@@ -14273,13 +14273,20 @@ xmltable_column_option_list:
xmltable_column_option_el:
IDENT b_expr
- { $$ = makeDefElem($1, $2, @1); }
+ {
+ if (strcmp($1, "__pg__is_not_null") == 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("option name \"%s\" cannot be used in XMLTABLE", $1),
+ parser_errposition(@1)));
+ $$ = makeDefElem($1, $2, @1);
+ }
| DEFAULT b_expr
{ $$ = makeDefElem("default", $2, @1); }
| NOT NULL_P
- { $$ = makeDefElem("is_not_null", (Node *) makeBoolean(true), @1); }
+ { $$ = makeDefElem("__pg__is_not_null", (Node *) makeBoolean(true), @1); }
| NULL_P
- { $$ = makeDefElem("is_not_null", (Node *) makeBoolean(false), @1); }
+ { $$ = makeDefElem("__pg__is_not_null", (Node *) makeBoolean(false), @1); }
| PATH b_expr
{ $$ = makeDefElem("path", $2, @1); }
;
diff --git a/src/test/regress/expected/xml.out b/src/test/regress/expected/xml.out
index bcc743f4851..103a22a3b1d 100644
--- a/src/test/regress/expected/xml.out
+++ b/src/test/regress/expected/xml.out
@@ -1373,6 +1373,10 @@ EXPLAIN (COSTS OFF, VERBOSE) SELECT * FROM xmltableview1;
-- errors
SELECT * FROM XMLTABLE (ROW () PASSING null COLUMNS v1 timestamp) AS f (v1, v2);
ERROR: XMLTABLE function has 1 columns available but 2 columns specified
+SELECT * FROM XMLTABLE (ROW () PASSING null COLUMNS v1 timestamp __pg__is_not_null 1) AS f (v1);
+ERROR: option name "__pg__is_not_null" cannot be used in XMLTABLE
+LINE 1: ...MLTABLE (ROW () PASSING null COLUMNS v1 timestamp __pg__is_n...
+ ^
-- XMLNAMESPACES tests
SELECT * FROM XMLTABLE(XMLNAMESPACES('http://x.y' AS zz),
'/zz:rows/zz:row'
diff --git a/src/test/regress/expected/xml_1.out b/src/test/regress/expected/xml_1.out
index a1c5d314171..73c411118a3 100644
--- a/src/test/regress/expected/xml_1.out
+++ b/src/test/regress/expected/xml_1.out
@@ -1047,6 +1047,10 @@ EXPLAIN (COSTS OFF, VERBOSE) SELECT * FROM xmltableview1;
-- errors
SELECT * FROM XMLTABLE (ROW () PASSING null COLUMNS v1 timestamp) AS f (v1, v2);
ERROR: XMLTABLE function has 1 columns available but 2 columns specified
+SELECT * FROM XMLTABLE (ROW () PASSING null COLUMNS v1 timestamp __pg__is_not_null 1) AS f (v1);
+ERROR: option name "__pg__is_not_null" cannot be used in XMLTABLE
+LINE 1: ...MLTABLE (ROW () PASSING null COLUMNS v1 timestamp __pg__is_n...
+ ^
-- XMLNAMESPACES tests
SELECT * FROM XMLTABLE(XMLNAMESPACES('http://x.y' AS zz),
'/zz:rows/zz:row'
diff --git a/src/test/regress/expected/xml_2.out b/src/test/regress/expected/xml_2.out
index 045641dae64..a85d95358d9 100644
--- a/src/test/regress/expected/xml_2.out
+++ b/src/test/regress/expected/xml_2.out
@@ -1359,6 +1359,10 @@ EXPLAIN (COSTS OFF, VERBOSE) SELECT * FROM xmltableview1;
-- errors
SELECT * FROM XMLTABLE (ROW () PASSING null COLUMNS v1 timestamp) AS f (v1, v2);
ERROR: XMLTABLE function has 1 columns available but 2 columns specified
+SELECT * FROM XMLTABLE (ROW () PASSING null COLUMNS v1 timestamp __pg__is_not_null 1) AS f (v1);
+ERROR: option name "__pg__is_not_null" cannot be used in XMLTABLE
+LINE 1: ...MLTABLE (ROW () PASSING null COLUMNS v1 timestamp __pg__is_n...
+ ^
-- XMLNAMESPACES tests
SELECT * FROM XMLTABLE(XMLNAMESPACES('http://x.y' AS zz),
'/zz:rows/zz:row'
diff --git a/src/test/regress/sql/xml.sql b/src/test/regress/sql/xml.sql
index 4c3520ce898..0ea4f508837 100644
--- a/src/test/regress/sql/xml.sql
+++ b/src/test/regress/sql/xml.sql
@@ -435,6 +435,8 @@ EXPLAIN (COSTS OFF, VERBOSE) SELECT * FROM xmltableview1;
-- errors
SELECT * FROM XMLTABLE (ROW () PASSING null COLUMNS v1 timestamp) AS f (v1, v2);
+SELECT * FROM XMLTABLE (ROW () PASSING null COLUMNS v1 timestamp __pg__is_not_null 1) AS f (v1);
+
-- XMLNAMESPACES tests
SELECT * FROM XMLTABLE(XMLNAMESPACES('http://x.y' AS zz),
'/zz:rows/zz:row'
--
2.43.0
* Re: Assert failure in base_yyparse
2025-03-28 07:39 Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-03-28 09:05 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-03-28 09:34 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-03-28 10:12 ` Re: Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-04-14 08:45 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-05-09 09:44 ` Re: Assert failure in base_yyparse Alvaro Herrera <alvherre@kurilemu.de>
2025-05-14 07:06 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
@ 2025-05-14 16:20 ` Alvaro Herrera <alvherre@kurilemu.de>
2025-05-15 08:55 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Alvaro Herrera @ 2025-05-14 16:20 UTC (permalink / raw)
To: Richard Guo <guofenglinux@gmail.com>; +Cc: Евгений Горбанев <gorbanyoves@basealt.ru>; pgsql-hackers@lists.postgresql.org
On 2025-May-14, Richard Guo wrote:
> Attached is a patch that implements this. It also renames the
> internally used option name and updates the error message.
LGTM.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Assert failure in base_yyparse
2025-03-28 07:39 Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-03-28 09:05 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-03-28 09:34 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-03-28 10:12 ` Re: Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-04-14 08:45 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-05-09 09:44 ` Re: Assert failure in base_yyparse Alvaro Herrera <alvherre@kurilemu.de>
2025-05-14 07:06 ` Re: Assert failure in base_yyparse Richard Guo <guofenglinux@gmail.com>
2025-05-14 16:20 ` Re: Assert failure in base_yyparse Alvaro Herrera <alvherre@kurilemu.de>
@ 2025-05-15 08:55 ` Richard Guo <guofenglinux@gmail.com>
0 siblings, 0 replies; 10+ messages in thread
From: Richard Guo @ 2025-05-15 08:55 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@kurilemu.de>; +Cc: Евгений Горбанев <gorbanyoves@basealt.ru>; pgsql-hackers@lists.postgresql.org
On Thu, May 15, 2025 at 1:20 AM Alvaro Herrera <alvherre@kurilemu.de> wrote:
> On 2025-May-14, Richard Guo wrote:
> > Attached is a patch that implements this. It also renames the
> > internally used option name and updates the error message.
> LGTM.
Thanks. I've pushed this patch and backpatched it through v15. I
didn't backpatch it to v14 or v13, as those branches don't use boolVal
to retrieve the value of the "is_not_null" option, so the assertion
failure doesn't occur there.
Thanks
Richard
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2025-05-15 08:55 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-03-28 07:39 Assert failure in base_yyparse Евгений Горбанев <gorbanyoves@basealt.ru>
2025-03-28 09:05 ` Richard Guo <guofenglinux@gmail.com>
2025-03-28 09:34 ` Richard Guo <guofenglinux@gmail.com>
2025-03-28 10:12 ` Евгений Горбанев <gorbanyoves@basealt.ru>
2025-04-14 08:45 ` Richard Guo <guofenglinux@gmail.com>
2025-05-09 05:54 ` Richard Guo <guofenglinux@gmail.com>
2025-05-09 09:44 ` Alvaro Herrera <alvherre@kurilemu.de>
2025-05-14 07:06 ` Richard Guo <guofenglinux@gmail.com>
2025-05-14 16:20 ` Alvaro Herrera <alvherre@kurilemu.de>
2025-05-15 08:55 ` Richard Guo <guofenglinux@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox