I'm not sure I understand the nature of the complaint, could you please elaborate on it? In particular,

• the options don't work (according to the comment)

This is an odd way to determine whether the options work or not.
Or, did you mean that the comments were wrong and must be removed?

The manual page that you quoted also gives a link to another page which explains in more detail what the option means:
http://dev.mysql.com/doc/refman/5.5/en/view-updatability.html

The WITH CHECK OPTION clause can be given for an updatable view to prevent inserts or updates to rows except those for which the WHERE clause in the select_statement is true.

It also gives examples which are easy to verify. The option seems to work as described in the manual.

• end-user applications will break when the options are actually implemented since the ambiguous statements will diverge in behavior

What ambiguous statements, how will they diverge in behavior, and what needs to be implemented to make it happen? Please provide examples.

• replication will not be backward-compatible for older slaves (using views)

Regardless the particular change we are talking about, it always happens whenever new functionality is implemented – the old slave is bound to fail when the new master uses new features, that's why NM=>OS replication is not guaranteed, even though there are continuous efforts to make it break as little as possible.

• the comments talk about "cascade/restrict", but the manual talks about "local and cascaded"

The comments are internal, and they don't say that they suggest the exact syntax; besides, how do you know that they refer to the "WITH CHECK OPTION"? 10 years ago people could think about lots of things when they wrote those comments, for example they could be planning to extend foreign keys syntax (which does have CASCADE/RESTRICT) onto views. We can try to ask them and see if they remember what the comments were about, if you insist it's important.

Elena:

There's no MariaDB code to implement the feature above, just a comment saying "TODO."

But because the feature was documented in the manual, users have been relying on the syntax.

Is that more clear?

James Briggs.

James Briggs

There's no MariaDB code to implement the feature above, just a comment saying "TODO."

But because the feature was documented in the manual, users have been relying on the syntax.

Is that more clear?

No, it's not. Once again – while reading the code is an admirable skill, sometimes it's worth taking a simple route, I don't understand why you're refusing to do it. Please do actually start the server and try the example from http://dev.mysql.com/doc/refman/5.5/en/view-updatability.html, it works exactly as described in the manual. Maybe then you'll be able to debug and find the code you've missed.

Please note that the manual does not mention any checks on DDL statements, only on INSERT/UPDATE.

Hi Elena.

Thanks, you're right - the comment refers to ALTER.

The functionality I was concerned about exists, which makes me happy. ( The code is in function sql/table.cc:TABLE_LIST::prep_check_option().)

However, likely the ALTER should be implemented, so either this JIRA should remain open, or reopened with a different title.
(I'll try to change the title.)

Thanks, James.

Hi James,

However, likely the ALTER should be implemented

and yet again, did you actually try it with ALTER?
What is it that's missing, comparing to the documentation? Please provide a complete example, in a form of a copy-paste from your MySQL client, with the expected results as opposed to the current results.

Thanks.

Closing as "Can't reproduce" for now, if you have more information, please comment to re-open.