Le 04/04/2022 à 18:20, Sebastien Flaesch a écrit :
P {margin-top:0;margin-bottom:0;} David,
Personally, I can see where it has significant value for psql in interactive mode because people make typos. Application code doesn't. That removes a whole class of problems where the feature provides benefit.
Sure, application code must not have typos, but I prefer to let the DB engine check for SQL constraints.
Imagine the following case:
BEGIN WORK
... (some other SQL) ...
DELETE FROM items WHERE item_id = 12823 -- Can raise foreign key error if sql-error then
...
To me it's better than:
BEGIN WORK
...
SELECT ... FROM orders WHERE item_id = 12823
if not-found then -- make sure we get no SQL error than cancels TX!
DELETE FROM items WHERE item_id = 12823
endif
...
... and not even sure it's valid atomic code depending on isolation level...
A good argument for PostgreSQL's behavior would be that it's better to cancel the whole transaction and restart all SQL commands.
However, legacy code is often spaghetti code where one function starts the TX, then calls other functions doing SQL ... ( yes, good candidate for savepoints usage! )
Anyway, thanks for the info, nothing planed short term, and that's what I was asking for.
Cheers!
Seb
FYI there was a discussion [1] and a patch to allow this feature through an extension because having this implemented in core will probably never happen. Everything was ready but the final status is Rejected so I don't think you might expect any planned work on this feature in any term. But who knows, things can evolve.
[1] https://www.postgresql.org/message-id/983d80b3-d187-127a-2de5-38c92ccb38ab%40darold.net
--
Gilles Darold
http://www.darold.net/
