Re: review: More frame options in window functions

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Feb 8, 2010 at 10:37 PM, Hitoshi Harada <umi.tanuki@gmail.com> wrote:
>> 2010/2/9 Tom Lane <tgl@sss.pgh.pa.us>:
>>> Given the lack of time remaining in this CF, I'm tempted to propose
>>> ripping out the RANGE support and just trying to get ROWS committed.
>>> That should be substantially less controversial from a semantic
>>> standpoint, and it still seems like a considerable improvement in
>>> functionality.
>> 
>> As expected. I don't mind splitting patch to be committable if users
>> who expected this feature don't mind.

> Well, they'll likely be happier with a partial feature than no feature
> at all...  I agree with Tom that there's no time time now to resolve
> the issue of how + and - should be handled.

I've done that and am reviewing the rest of the patch, but I had more
trouble than I expected with phrasing the "not implemented" message.
Usually we try to word these things like "SQLCOMMAND is not implemented"
but there's no one-word version of what it is that's been left out.
"RANGE" isn't right since there are variants of RANGE that work.
What I have at the moment is
       if (n->frameOptions & (FRAMEOPTION_START_VALUE_PRECEDING |
FRAMEOPTION_END_VALUE_PRECEDING))          ereport(ERROR,                   (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
               errmsg("RANGE value PRECEDING is not implemented yet"),                    parser_errposition(@1)));
 if (n->frameOptions & (FRAMEOPTION_START_VALUE_FOLLOWING |
FRAMEOPTION_END_VALUE_FOLLOWING))          ereport(ERROR,                   (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
               errmsg("RANGE value FOLLOWING is not implemented yet"),                    parser_errposition(@1)));
 

but I wonder if anyone has a better idea.
        regards, tom lane