Re: (PATCH) Adding CORRESPONDING (NULL error)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kerem Kat <keremkat(at)gmail(dot)com>
Cc: Erik Rijkers <er(at)xs4all(dot)nl>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: (PATCH) Adding CORRESPONDING (NULL error)
Date: 2011-10-27 21:04:55
Message-ID: 5792.1319749495@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kerem Kat <keremkat(at)gmail(dot)com> writes:
> On Thu, Oct 27, 2011 at 23:20, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> BTW, just to clarify: although that case fails, the case Erik was
>> complaining of does work in unmodified Postgres:
>> ...
>> and I agree with him that it should still work with CORRESPONDING.

> That is by design, because CORRESPONDING is implemented as subqueries:

Well, this appears to me to be a counterexample sufficient to refute
that implementation decision. You can inject subqueries at plan time,
if that helps you make things match up, but you can't rearrange things
that way at parse time, as I gather you're doing or else you would not
be seeing this problem. In any case, I already pointed out to you that
rearranging the parse tree that way is problematic for reverse-listing
the parse tree. We don't want to see subqueries injected in the results
of printing parse trees with ruleutils.c.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Redekop 2011-10-27 21:09:40 Re: Hot Standby startup with overflowed snapshots
Previous Message Bruce Momjian 2011-10-27 21:02:49 Re: pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces