Alex Peshkov wrote:

> If we plan to support MATCHING, we can't support RETURNING at the same
> time in 2.1. A compromise may be to support MATCHING and RETURNING not
> at the same time, i.e. one may type:
> REPLACE INTO <table> [(<field_list>)] VALUES (<value_list>) MATCHING
> (<field_list>)
> or
> REPLACE INTO <table> [(<field_list>)] VALUES (<value_list>) [RETURNING
> <field_list>]
>
> In the second case (no MATCHING clause) PK is used, making update of
> only single row possible, therefore we can have singleton RETURNING.
> This form is also useful because most of REPLACE in well-formed database
> should use PK, and this syntax saves some typing and therefore helps
> end-user avoid some errors.
>
> In the future, when we will learn to support RETURNING multiple rows,
> form without MATCHING (using PK), will remain useful anyway.
>

Without MATCHING, a new BLR verb will be required to create a dependency
on the PK.
Initial implementation was proved that is much better to create the RSE
in DSQL instead of in the engine.
And then what this new verb will do, only to store that dependency?

Or maybe generate a blr_plan with the PK index in the RSE?

Anyway, isn't a singleton RSE sufficient for a MATCHING...RETURNING for now?


Adriano