On Mon, May 17, 2010 at 9:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, May 17, 2010 at 4:01 PM, Tom Lane <t...@sss.pgh.pa.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.
Well, I guess it boils down to what you think the chances that this change will unintentionally break something are, then. I don't have a good feeling for that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
