Обсуждение: WARNING: outfuncs/readfuncs failed to produce an equal rewritten parse tree
Hi
Last time I wrote new tests for session variables.
One is
create variable :"DBNAME".public.var as int;
On platform with enabled WRITE_READ_PARSE_PLAN_TREES I got warning
"WARNING: outfuncs/readfuncs failed to produce an equal rewritten parse tree"
After some investigation, I found a problem in the RangeVar node.
The field "catalogname" is setted to NULL in _readRangeVar, but it is compared in _equalRangeVar function.
I thought so it is problem in my patch, but it looks like generic issue:
create table postgres.public.foo(a int);
WARNING: outfuncs/readfuncs failed to produce an equal rewritten parse tree
CREATE TABLE
CREATE TABLE
Is it a known issue?
Regards
Pavel
Pavel Stehule <pavel.stehule@gmail.com> writes:
> After some investigation, I found a problem in the RangeVar node.
> The field "catalogname" is setted to NULL in _readRangeVar, but it is
> compared in _equalRangeVar function.
> I thought so it is problem in my patch, but it looks like generic issue:
> create table postgres.public.foo(a int);
> WARNING: outfuncs/readfuncs failed to produce an equal rewritten parse tree
> CREATE TABLE
Heh. Probably we should just drop that special treatment of the
catalogname field --- that was always premature optimization,
given that (I think) we don't ever store RangeVar in the catalogs.
The alternative would be to also lobotomize comparisons of RangeVars
by marking the field equal_ignore, but what's the point?
regards, tom lane
Re: WARNING: outfuncs/readfuncs failed to produce an equal rewritten parse tree
От
Pavel Stehule
Дата:
po 23. 1. 2023 v 17:31 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> After some investigation, I found a problem in the RangeVar node.
> The field "catalogname" is setted to NULL in _readRangeVar, but it is
> compared in _equalRangeVar function.
> I thought so it is problem in my patch, but it looks like generic issue:
> create table postgres.public.foo(a int);
> WARNING: outfuncs/readfuncs failed to produce an equal rewritten parse tree
> CREATE TABLE
Heh. Probably we should just drop that special treatment of the
catalogname field --- that was always premature optimization,
given that (I think) we don't ever store RangeVar in the catalogs.
+1
Regards
Pavel
The alternative would be to also lobotomize comparisons of RangeVars
by marking the field equal_ignore, but what's the point?
regards, tom lane