Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, May 17, 2014 at 1:02 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>> We have a long tradition of trying to allow noise keywords where it's
>> harmless.
>>
>> So the clause should probably be
>>
>> SKIP LOCKED [DATA]
>>
>> in much the same way we have
>>
>> BEGIN [ WORK | TRANSACTION ] ...
>>
>> There won't be any ambiguity there.
> We've had some problems in the past where allowing optional noise
> words resulted in grammar conflicts that made future features harder
> to add.
In this particular case, I'd be worried about whether we'd not end up
having to fully reserve DATA in order to allow it to be optional here.
That would be necessary if this clause could be followed immediately
by an identifier, either now or in the future. That would be a mighty
high price to pay for failing to make up our minds about which syntax
to use. (How many tables out there do you think have "data" as a column
name?)
A different concern is that this patch adds not one but two new unreserved
keywords, ie SKIP and LOCKED. That bloats our parser tables, which are
too darn large already, and it has a nonzero compatibility cost (since
we only allow AS-less column aliases when they are no keyword at all).
If we're pulling syntax out of the air it'd be nice if we could avoid
adding new keywords to the grammar.
regards, tom lane
