On Mon, May 17, 2010 at 9:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, May 17, 2010 at 4:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Perhaps this is a backpatchable bug fix. Comments?
>> I can't say whether this is safe enough to back-patch, but the way
>> this is set up, don't we also need to fix some catalog entries and, if
>> yes, isn't that problematic?
> The only catalog entries at issue, AFAICT, are the textanycat/anytextcat
> ones. I am not sure whether we should attempt to back-patch changes for
> them, but this patch wouldn't make the situation in the back branches
> worse. In particular, if we apply this patch but don't change the
> catalog entries, then nothing would change at all about the problematic
> cases, because the planner would decide it couldn't safely inline the
> function. The only cases where inlining will happen is where the
> expression's apparent volatility stays the same or decreases, so as far
> as that issue is concerned this patch will never make CREATE INDEX
> reject a case it would have accepted otherwise. The patch *will* make
> CREATE INDEX reject cases with volatile default arguments hiding under
> non-volatile functions, but that's got nothing to do with any built-in
> functions; and that's the case I claim is clearly a bug fix.
This is still on the 9.0 open items list, but ISTM you fixed it with
two commits on May 27th. Is that correct?
The Enterprise Postgres Company
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-05-29 21:09:02|
|Subject: Re: PG 9.0 release timetable|
|Previous:||From: Bruce Momjian||Date: 2010-05-29 20:19:53|
|Subject: PG 9.0 release timetable|