The error message for user connections using insecure transport when secured transport is required is very uninformative and doesn't mention the requirement of secure
transport at all.
To make the error message more relevant, introduce a new error
'ER_SECURE_TRANSPORT_REQUIRED', copy of MySQL error message with the
error code 08004 (SQL-server rejected establishment SQL-connection).
Move the code of 'require_secure_transport' to be executed before
authentication verification, as it's not part of authentication but
rather verifying if connection should be allowed in the first place.
All new code of the whole pull request, including one or several files that
are either new files or modified ones, are contributed under the BSD-new license.
I am contributing on behalf of my employer Amazon Web Services, Inc.
Instructions and a script to help speed up language translations
for MariaDB are provided. The README.md provides instructions of
a recommended workflow that involves:
- Extracting the English language entries in the file
errmsg-utf8.txt
- Using online tools to do automatic translation.
- Proof-reading the automatic translations.
- Running the script insert_translations_into_errmsg.py that
will take the original errmsg-utf8.txt file, the extracted
english translations file and the new language translations
file and generate a new file errmsg-utf8-with-new-language.txt
that is a copy of errmsg-utf8.txt but with the new language
entries inserted into it at the correct positions.
All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services, Inc.
Kenyan Swahili is enabled for error messages as well as datetime.
All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services, Inc.
* removed universal suppression of everything "Event Schedule" everywhere
* added suppressions in tests as needed
* moved events test to the events suite
* renamed -master.opt -> .opt
* added standard test header
* verified in the test that the error, indeed, was written into the log
* removed useless suppressions
* removed ER_EVENTS_NO_ACL, replaced with ER_OPTION_PREVENTS_STATEMENT
* fixed error message to say exactly what option disabled event scheduler
instead of "this or that or that, you figure it out"
* also fixed old message for SET event_scheduler=
(it was also non-translatable)
* changed to use sql_print_error() when an error is not sent to the user
* removed duplicate hard-coded error message
When the server is started with `--event-scheduler=ON` and with
`--skip-grant-tables` (or built as embedded server which has no grant
tables at all), the event scheduler *appears* to be enabled (`SELECT
@@global.event_scheduler` returns `'ON'`), but attempting to
manipulate it in any way returns a misleading error message:
"Cannot proceed, because event scheduler is disabled"
Possible solutions:
1. Fast-fail: fail immediately on startup if `EVENT_SCHEDULER` is set to
any value other than `DISABLED` when starting up without grant
tables, then prevent `SET GLOBAL event_scheduler` while running.
Problem: there are existing setup scripts and code which start with
this combination and assume it will not fail.
2. Warn and change value: if `EVENT_SCHEDULER` is set to any value
other than `DISABLED` when starting, print a warning and change it
immediately to `DISABLED`.
Advantage: The value of the `EVENT_SCHEDULER` system variable after
startup will be consistent with its functional unavailability.
3. Display a clear error: if `EVENT_SCHEDULER` is enabled, but grant
tables are not enabled, then ensure error messages clearly explain
the fact that the combination is not supported.
Advantage: The error message encountered by the end user when
attempting to manipulate the event scheduler (such as `CREATE
EVENT`) is clear and explicit.
This commit implements the combination of solutions (2) and (3): it
will set `EVENT_SCHEDULER=DISABLED` on startup (reflecting the
functional reality) and it will print a startup warning, *and* it will
print a *distinct* error message each time that an end user attempts to
manipulate the event scheduler, so that the end user will clearly understand
the problem even if the startup messages are not visible at that point.
It also adds an MTR test `main.events_skip_grant_tables` to verify the
expected behavior, and the unmodified `main.events_restart` test
continues to demonstrate no change in the error message when the event
scheduler is non-functional for *different* reasons.
All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the BSD-new
license. I am contributing on behalf of my employer Amazon Web Services
Implementation:
Implementation is made according to json schema validation draft 2020
JSON schema basically has same structure as that of json object, consisting
of key-value pairs. So it can be parsed in the same manner as
any json object.
However, none of the keywords are mandatory, so making guess about the
json value type based only on the keywords would be incorrect.
Hence we need separate objects denoting each keyword.
So during create_object_and_handle_keyword() we create appropriate objects
based on the keywords and validate each of them individually on the json
document by calling respective validate() function if the type matches.
If any of them fails, return false, else return true.
Charset names in the 'languages' line are not used any more.
Removing to avoid confusion.
All messages in errmsg-utf8.txt are in utf8 now.
Charset names should have been removed in MySQL-5.5 during: https://dev.mysql.com/worklog/task/?id=751
Bump version number.
The error string from ER_KILL_QUERY_DENIED_ERROR took a different
type to ER_KILL_DENIED_ERROR for the thread id. This shows
up in differences on 32 big endian arches like powerpc (Deb notation).
Normalize the passing of the THD->id to its real type of my_thread_id,
and cast to (long long) on output. As such normalize the
ER_KILL_QUERY_DENIED_ERROR to that convention too.
Note for upwards merge, convert the type to %lld on new translations
of ER_KILL_QUERY_DENIED_ERROR.
For commands
(1) alter table t1 add partition (partition p2);
(2) alter table t1 add partition (partition px history);
It printed the same error message:
Wrong partitioning type, expected type: `SYSTEM_TIME`
For (1) it is not clear from the syntax that we are trying to add
HASH partition. For (2) it is not clear that the table partitioning is
different than SYSTEM_TIME. Now it prints what type we are trying to
add to what type of partitioning.
Fixed warning unused function rename_field_in_list() for compilation
without partitioning.
For commands
(1) alter table t1 add partition (partition p2);
(2) alter table t1 add partition (partition px history);
It printed the same error message:
Wrong partitioning type, expected type: `SYSTEM_TIME`
For (1) it is not clear from the syntax that we are trying to add
HASH partition. For (2) it is not clear that the table partitioning is
different than SYSTEM_TIME. Now it prints what type we are trying to
add to what type of partitioning.
1. system_versioning_insert_history session variable allows
pseudocolumns ROW_START and ROW_END be specified in INSERT,
INSERT..SELECT and LOAD DATA.
2. Cleaned up select_insert::send_data() from setting vers_write as
this parameter is now set on TABLE initialization.
4. Replication of system_versioning_insert_history via option_bits in
OPTIONS_WRITTEN_TO_BIN_LOG.
If repl.max_ws_size is set too low following CREATE TABLE could fail
during commit. In this case wsrep_commit_empty should allow rolling
it back if provider state is s_aborted.
Furhermore, original ER_ERROR_DURING_COMMIT does not really tell anything
clear for user. Therefore, this commit adds a new error
ER_TOO_BIG_WRITESET. This will change some test cases output.
- Added missing information about database of corresponding table for various types of commands
- Update some typos
- Reviewed by: <vicentiu@mariadb.org>
