-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix: no table selected #643
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than modifying the existing method, perhaps we could use a getRandomTableOrBailout
method such as the one below that throws an exception when no table exists? In many contexts, it might be clear that a table exists, and not throwing an exception in such cases might help detect otherwise overlooked bugs (in SQLancer).
I think it should be a bug as all dbs assume the returned list has at least one table and directly operate the object. |
I cannot remember it exactly, but it should be some corner cases in which no table is returned, but there is no bug. |
Like this, it gets a random table and assumes the returned list is not empty:
But its assumption is not always true. It is a potential bug that was not exposed before. |
We can close it as it is, and apply this fix when observing this issue again. |
Pull request was closed
Not sure if I would call this a bug - all implementations relying on this method indeed assume that at least one table exists, and I can't think of a circumstance where this doesn't hold. Did QPG result in a corner case where this assumption no longer holds? If so, perhaps we can rename |
Okay, sounds good. |
When no table is selected, the execution should be aborted to avoid execution errors in QPG.