On 26-11-2021 17:13, Tony Whyman wrote:
On 26/11/2021 15:43, Dimitry Sibiryakov wrote:
Tony Whyman wrote 26.11.2021 16:32:
What you appear to be saying is that you have changed/expanded the
semantic of Update...Returning, changed the SQL Statement type
returned and then not expected the change to break any existing code...
Correction: any sane code.
There is an old joke that starts with one person asking another the way
to Edinburgh. The answer given is "I wouldn't start from here if I were
you".
That answer may be true, but very unhelpful. Legacy code can often
appear "insane" with the benefit of hindsight. The problem is that it
exists and it is your starting point. You don't break it without good
reason.
There is a good reason: supporting multi-row RETURNING instead of the
limitation in FB 4.0 and earlier of only supporting singleton updates.
And this is done in a way that query tools and drivers inspecting the
statement type will still be able to process it appropriately.
The reasoning is similar as why isc_info_sql_stmt_exec_procedure was
used when RETURNING was introduced in Firebird 2.0[1]:
"""
If the RETURNING clause is present, then the statement is described as
isc_info_sql_stmt_exec_procedure by the API (instead of
isc_info_sql_stmt_insert), so the existing connectivity drivers should
support this feature automagically.
"""
Maybe Firebird shouldn't have implemented RETURNING at all, but instead
implemented the SQL standard way of doing this using the data change
delta table:
`select * from final table (update sometable set x = 'a')`
(or `select * from new table (update sometable set x = 'a')` or `select
* from old table (update sometable set x = 'a')`)
However, the semantics of supporting data change delta table is a bit
more complex (from a quick read of the standard).
Mark
[1]:
https://firebirdsql.org/file/documentation/release_notes/html/rlsnotes207.html#dml-dsql-returning
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
