Re: COALESCE implementation question - Mailing list pgsql-hackers

From Tom Lane
Subject Re: COALESCE implementation question
Date
Msg-id 23985.965537417@sss.pgh.pa.us
Whole thread Raw
In response to Re: COALESCE implementation question  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Philip Warner <pjw@rhyme.com.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


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: LIKE/ESCAPE implementation
Next
From: Tom Lane
Date:
Subject: Re: OK to remove operators for exp() and ln()