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
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 |