On Fri, Jan 7, 2022 at 12:24 AM Tom Lane wrote:
> Amit Langote writes:
> > Thanks for addressing that in the patch you posted. I guess fixing
> > only expression_tree_walker/mutator() suffices for now, but curious to
> > know if it was intentional that you decided not to touch the following
> >
Amit Langote writes:
> Thanks for addressing that in the patch you posted. I guess fixing
> only expression_tree_walker/mutator() suffices for now, but curious to
> know if it was intentional that you decided not to touch the following
> sites:
> exprCollation(): it would perhaps make sense to r
On Mon, Dec 20, 2021 at 4:20 PM Tom Lane wrote:
> pg_get_expr doesn't (or didn't) depend on expression_tree_walker,
> so there wasn't a problem there before. I am worried that there
> might be other code paths, now or in future, that could try to apply
> expression_tree_walker/mutator to relpartb
On Thu, Jan 6, 2022 at 3:43 PM Amit Langote wrote:
> On Tue, Dec 21, 2021 at 6:20 AM Tom Lane wrote:
> > Robert Haas writes:
> > > OK ... but my point is that dump and restore does work. So whatever
> > > cases pg_get_expr() doesn't work must be cases that aren't needed for
> > > that to happen.
On Tue, Dec 21, 2021 at 6:20 AM Tom Lane wrote:
> Robert Haas writes:
> > OK ... but my point is that dump and restore does work. So whatever
> > cases pg_get_expr() doesn't work must be cases that aren't needed for
> > that to happen. Otherwise this problem would have been found long ago.
>
> pg
Here's a less hasty version of the patch.
regards, tom lane
diff --git a/src/backend/nodes/nodeFuncs.c b/src/backend/nodes/nodeFuncs.c
index e276264882..5d4700430c 100644
--- a/src/backend/nodes/nodeFuncs.c
+++ b/src/backend/nodes/nodeFuncs.c
@@ -2201,6 +2201,26 @@ express
Robert Haas writes:
> OK ... but my point is that dump and restore does work. So whatever
> cases pg_get_expr() doesn't work must be cases that aren't needed for
> that to happen. Otherwise this problem would have been found long ago.
pg_get_expr doesn't (or didn't) depend on expression_tree_walk
On Mon, Dec 20, 2021 at 2:36 PM Tom Lane wrote:
> I'm not sure why you're astonished by that, considering that
> psql has applied pg_get_expr to relpartbound since f0e44751d,
> which was the same commit that put code into ruleutils.c to
> make pg_get_expr work on relpartbounds.
>
> It seems a bit
Robert Haas writes:
> Right. I'm not surprised that relpartbound uses those node types. I
> *am* surprised that pg_get_expr() is expected to be able to handle
> them. IOW, they ARE node trees, consonant with the fact that the
> column type is pg_node_tree, but they're NOT expressions.
I'm not sur
On Mon, Dec 20, 2021 at 1:13 PM Tom Lane wrote:
> The reason the regression tests fail if I only patch ruleutils is
> that psql \d on a partitioned table invokes
> ... pg_get_expr(c.relpartbound, c.oid) FROM pg_catalog.pg_class c
> and evidently relpartbound does contain precisely these no
Robert Haas writes:
> The commit that added PartitionBoundSpec and PartitionRangeDatum was
> committed by me and authored by Amit Langote. It is the original table
> partitioning commit -- f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63. I'm
> reasonably sure that the reason why those didn't get added to
On Mon, Dec 20, 2021 at 11:25 AM Tom Lane wrote:
> I figured this would be just a quick hack in ruleutils.c, but was
> dismayed to find the regression tests falling over, because some
> bozo neglected to teach nodeFuncs.c about partition expressions.
> It might be a good idea to back-patch that pa
Robert Haas writes:
> On Sun, Dec 19, 2021 at 4:17 PM Tom Lane wrote:
>> I don't see anything particularly surprising here. pg_get_expr is only
>> able to cope with expression trees over a single relation, but ON UPDATE
>> rules can refer to both OLD and NEW relations. Maybe we could make the
>
On Sun, Dec 19, 2021 at 4:17 PM Tom Lane wrote:
> Justin Pryzby writes:
> > I reduced the problematic query to this.
> > SELECT 1 FROM pg_rewrite WHERE
> > pg_get_function_arg_default(ev_class, 1) !~~
> > pg_get_expr(ev_qual, ev_class, false);
>
> Or more simply,
>
> regression=# select pg_get_ex
Justin Pryzby writes:
> I reduced the problematic query to this.
> SELECT 1 FROM pg_rewrite WHERE
> pg_get_function_arg_default(ev_class, 1) !~~
> pg_get_expr(ev_qual, ev_class, false);
Or more simply,
regression=# select pg_get_expr(ev_qual, ev_class, false) from pg_rewrite where
rulename = 'p
I reduced the problematic query to this.
SELECT 1 FROM pg_rewrite WHERE
pg_get_function_arg_default(ev_class, 1) !~~
pg_get_expr(ev_qual, ev_class, false);
#0 pg_re_throw () at elog.c:1800
#1 0x563f5d027932 in errfinish () at elog.c:593
#2 0x563f5cb874ee in resolve_special_varno (node=
16 matches
Mail list logo
