Horton

Thread

Commits

  1. Remove special outfuncs/readfuncs handling of RangeVar.catalogname.

  1. WARNING: outfuncs/readfuncs failed to produce an equal rewritten parse tree

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-01-23T15:53:41Z

    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

Is it a known issue?

Regards

Pavel

  2. Re: WARNING: outfuncs/readfuncs failed to produce an equal rewritten parse tree

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-01-23T16:31:44Z

    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

  3. Re: WARNING: outfuncs/readfuncs failed to produce an equal rewritten parse tree

    Pavel Stehule <pavel.stehule@gmail.com> — 2023-01-23T16:46:24Z

    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
>