[MDEV-14449] mysqldump error messages Created: 2017-11-20  Updated: 2017-12-25  Resolved: 2017-12-25

Status: Closed
Project: MariaDB Server
Component/s: Scripts & Clients
Affects Version/s: 10.2.10
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Michal Schorm Assignee: Sergei Golubchik
Resolution: Not a Bug Votes: 0
Labels: None


 Description   

Hello,
I talked with a guy in Fedora, who pointed out interesting issue.
I'd like to know your opinion and if positive, add it as a feature request.

With following call:

$ /usr/bin/mysqldump "" --add-locks -e --force -R --triggers --add-drop-table --hex-blob -h localhost test
 
-- MySQL dump 10.16  Distrib 10.2.9-MariaDB, for Linux (x86_64)
--
-- Host: localhost    Database: 
-- ------------------------------------------------------
-- Server version	10.2.9-MariaDB
 
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
mysqldump: Got error: 1046: "No database selected" when selecting the database
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
 
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
 
-- Dump completed on 2017-11-20 15:02:20

You can see the:
"mysqldump: Got error: 1046: "No database selected" when selecting the database"
in the middle.

But that is basically nonsense, because the binary parsed an empty argument. Because DB name cannot be an empty string, it better should just skip the argument.

This issue appears, when user use scripts for work with the database and at some point a "" (empty string) can be left inside the command, which is later parsed incorrectly.

The question is, whether you consider it as a faulty user script design or if you agree, that emtpy argument should be skipped.

A little messy - but complete - discussion can be seen here:
https://bugzilla.redhat.com/show_bug.cgi?id=1320593



 Comments   
Comment by Elena Stepanova [ 2017-11-20 ]

It seems to be a rather standard behavior, like

$ ls "" foo
ls: cannot access : No such file or directory
ls: cannot access foo: No such file or directory

$ find "" foo -name bar
find: cannot search `': No such file or directory
find: `foo': No such file or directory

None of the above ignores an empty argument, even though it's obviously wrong.

As a user/writer of simple scripts, I agree that it does indeed cause minor difficulties in scripting, but at the end it's probably worth it. If I generate a command line and end up with an empty something, I'd rather know about it than miss something crucially important because it was generated wrongly.

mschorm,

If you want a wider audience / participation, maybe sending the question to a mailing list would be more efficient.

Comment by Michal Schorm [ 2017-11-20 ]

Ok. I agree with you it is standard behaviour and I came here to hear your opinion - which I can realate to too.
I considered asking on mailing list instead, however I'd rather hear your opinion first.

In that case, however, a different error message could help people recognize the issue.
So instead "No database selected" something like "empty argument has been parsed" could be quite helpful message. Don't you think?

Generated at Thu Feb 08 08:13:39 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.