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

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
>

In response to

Browse pgsql-hackers by date

  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