From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: WARNING: outfuncs/readfuncs failed to produce an equal rewritten parse tree |
Date: | 2023-01-23 16:46:24 |
Message-ID: | CAFj8pRAbVu_bMRRz0fZwH7iznzTjD0jUYw1Dnmbns=kAWS2ocQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
po 23. 1. 2023 v 17:31 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2023-01-23 16:54:00 | Re: MERGE ... RETURNING |
Previous Message | Robert Haas | 2023-01-23 16:34:32 | Re: Non-superuser subscription owners |