Mark,
>> I'm looking at the patch, please be patient ;-)
>
> Any news on this?
I don't have any major problems with the patch. Just a few questions:
1) Why have you decided to extend select_expr via duplication rather
than using something like this:
%type <selectExprNode> select_expr
select_expr
: with_clause select_expr_body order_clause limit_clause2
{
SelectExprNode* node = $$ = newNode<SelectExprNode>();
node->querySpec = $2;
node->orderClause = $3;
node->rowsClause = $4;
node->withClause = $1;
}
;
%type <rowsClause> limit_clause2
limit_clause2
: rows_clause
{ $$ = $1; }
| result_offset_clause fetch_first_clause
{
if ($1 || $2) {
RowsClause* rowsNode = newNode<RowsClause>();
rowsNode->skip = $1;
rowsNode->length = $2;
$$ = rowsNode;
} else {
$$ = NULL;
}
}
;
2) You have left non-standard ROWS clause for searched UPDATE/DELETE
statements because the standard does not define OFFSET/FETCH for them,
right? In this case, generic recommendation to use OFFSET/FETCH instead
of the [deperecated] ROWS looks too hard, as ROWS remains pretty valid
(and the only option) for UPDATE/DELETE.
Would it make sense to adapt OFFSET/FETCH for UPDATE/DELETE as well? Or
does it sound too weird for end-users (we're updating/deleting, not
fetching)?
3) New reserved words (OFFSET and ROW) should be added to the
keyword_or_column rule to simplify migration. That said, I'm wondering
why ROWS wasn't added there too in v2.0. Probably my oversight.
Dmitry
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
