From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | pgsql-hackers(at)hub(dot)org |
Subject: | Re: COALESCE implementation question |
Date: | 2000-08-06 04:50:17 |
Message-ID: | 23985.965537417@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
>> This is a bug caused by interaction between two planning passes run
>> on the same Query node. The parser thinks it's cool to generate a
>> CASE parsetree with multiple paths to the same sub-select Query node,
>> but in fact it is not cool because planning destructively alters the
>> Query node contents. I'm amazed it didn't crash, to tell the truth.
>>
>> I have a patch but haven't applied it yet (been offline for most of
>> two days due to telco idiocy :-().
> Thanks for this; I must admit I was very surprised not to get a response
> withing 24 hours! Is there any chance of sending me the patch - I have been
> looking at the sources for a while now, and it would be nice to see the
> answer...
Well, I'm not *proud* of this patch, it's pretty much brute-force.
But it will do until we get around to redesigning querytrees.
See src/backend/optimizer/plan/subselect.c.
I imagine the diff would apply to 7.0.* if you want to do that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2000-08-06 04:51:05 | Re: LIKE/ESCAPE implementation |
Previous Message | Thomas Lockhart | 2000-08-06 04:24:10 | OK to remove operators for exp() and ln() |