[progmetaldev]

I know what you mean, I do the same. I agree, but at the same time, it's difficult to start building in protections for the user. Where do you start and where do you stop? I have been forced to do the extreme to protect the user, and then you are asked why things are so difficult to use. I think to make something for someone that concentrates in the technology, as well as a beginner, means you've got to give up so much power (or create a secondary syntax/interface for both audiences). It would be nice to be able to set modes, but then it's going to be database specific unless it has proven itself to be useful across engines. Like most standardization, then you play syntax games between vendors. It would be nice to at least be able to write an UPDATE or DELETE statement with a leading character or keyword to display affected rows.

[kristopolous]

It's completely Optional safeguards. Add long as it's optional, I advocate for having as many of those as people can imagine

[progmetaldev]

I understand, but with how much of a change to the language? Such a change would take an enormous amount of time to make it into the ANSI/ISO SQL standard, and what database would start to implement it first, and which would hold out as long as possible?

I don't disagree that it's impossible, but how do you get the syntax standardized at this point? Do you get various dialects, or an agreement between vendors? Look how slowly the standard moves, when do we get this where it's usable in most popular RDBMS?

[kristopolous]

The venn diagram of query support between SQL vendors is much closer to a flower than you think.

Just implement it for one and if it works, the others will add it

[progmetaldev]

I have upvoted you for each comment you've made, but I feel like it's not that simple. Even just getting a single vendor to implement it is a huge undertaking. I know that you and I see the value in it, but I don't feel like we're the first to see that. There's a reason behind not implementing this feature, and it's the complexity that lies behind such a feature, like most things. This seems like one of those recursive and interactive features that don't fit into SQL. Does it present the rows that will be updated or deleted, and then ask if you wish to perform the operation? That doesn't work like anything SQL based, and I feel that's why we don't have it. I appreciate the back and forth on this, and am curious as to how you think it should be handled, if there's a way to fit in the way SQL works.

[kristopolous]

If the expectation is not met then it rolls back and fails. I implemented a slipshod version of it years ago for a previous employer (it got the job done with a lousier syntax)

Here's a list of 1,000 postgres extensions, it's not a big deal: https://gist.github.com/joelonsql/e5aa27f8cc9bd22b8999b7de8a...

Things are way more modular than they used to be.

I can probably do it again and just try to get attention for it.

[specialist]

From the hip, maybe something like "UPDATE DRYRUN ...". It'd report how many rows would be updated.

Or... "DRYRUN UPDATE ...", which is more like "EXPLAIN UPDATE..."

Thoughts?

[progmetaldev]

Sounds like a solid idea, but I feel like just replacing your UPDATE with a SELECT COUNT(whatever_column_is_indexed_from_your_where) would be a good practice. If your DBMS supports an external language, that might be the best idea, so you can write your own logic, while keeping mostly everything in the database itself.

I only mean this from a more ANSI SQL side of things, where you might want to build your skills up to use as much of the standard as possible, until it's no longer possible and make sense to dip into platform specifics. I used to build code around being cross-platform, but at the same time realized that it's more useful to learn the ANSI standard, and then break free with LOTS of useful comments where it makes sense to do things more efficiently and with safety that you don't get normally.