Re: abstract: fix poor constant folding in 7.0.x, fixed in 7.1?

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [001207 16:45] wrote:
> Alfred Perlstein <bright(at)wintelcom(dot)net> writes:
> > Each function should have a marker that explains whether when given
> > a const input if the output might vary, that way subexpressions can
> > be collapsed until an input becomes non-const.
>
> We already have that and do that.
>
> The reason the datetime-related routines are generally not marked
> 'proiscachable' is that there's this weird notion of a CURRENT time
> value, which means that the result of a datetime calculation may
> vary depending on when you do it, even though the inputs don't.
>
> Note that CURRENT here does not mean translating 'now' to current
> time during input conversion, it's a special-case data value inside
> the system.
>
> I proposed awhile back (see pghackers thread "Constant propagation and
> similar issues" from mid-September) that we should eliminate the CURRENT
> concept, so that datetime calculations can be constant-folded safely.
> That, um, didn't meet with universal approval... but I still think it
> would be a good idea.

I agree with you that doing anything to be able to fold these would
be nice. However there's a hook mentioned in my abstract that
explains that if a constant makes it into a function, you can
provide a hook so that the function can return whether or not that
constant is cacheable.

If the date functions used that hook to get a glimpse of the constant
data passed in, they could return 'cachable' if it doesn't contain
the 'CURRENT' stuff you're talking about.

something like this could be called on input to "maybe-cachable"
functions:

int
date_cachable_hook(const char *datestr)
{

if (strcasecmp("current", datestr) == 0)
return (UNCACHEABLE);
return (CACHEABLE);
}

Or maybe I'm missunderstanding what CURRENT implies?

I do see that on:
http://www.postgresql.org/mhonarc/pgsql-hackers/2000-09/msg00408.html

both you and Thomas Lockhart agree that CURRENT is a broken concept
because it can cause btree inconsistancies and should probably be
removed anyway.

No one seems to dispute that, and then the thread leads off into
discussions about optimizer hints.

> In the meantime you can cheat by defining functions that you choose
> to mark ISCACHABLE, as has been discussed several times in the archives.

Yes, but it doesn't help the niave user (me :) ) much. :(

Somehow I doubt that if 'CURRENT' was ifdef'd people would complain.

--
-Alfred Perlstein - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
"I have the heart of a child; I keep it in a jar on my desk."