SphinxQL Error on Show Meta; - sphinx

As far as I know I can run
Show Meta;
After doing a SphinxQL search to see what Sphinx is actually searching for.
However I keep getting
sphinxql: syntax error, unexpected SUBKEY, expecting $end near '.PROFILING GROUP BY QUERY_ID'
Yet my searches seem to work fine. Is my syntax wrong or is there something in my index itself I should explore or look for?

In editions past 11 in Navicat, go to View Menu and deselect 'Show Profile and Status'

Related

Aginity SQL error message shows wrong character

When I make a query in Aginity with an error in it, it gives a notification like
ERROR: '[My SQL here]'
error
^ found "INSERT" (at char 2292) expecting `SELECT' or `'(''
If I click on the location of that error in my SQL, it's actually at Position: 3934. I think Aginity is disregarding the whitespace when it tries to say where the error is. Is there a way to make it show the position in the builder?
It's not Aginity that does this, it's somewhere up the software stack (I suspect it's on the actual Netezza itself).
What I do (and this is a POOR solution) is to remove the whitespace myself.
Since I use Unix (mostly) and Vim this is a little easier than in Aginity.
It really is a PITA, and IBM should proved a better solution (one would be to kick back the SQL statement as run with all the whitespace removed).

VSCode query format for searching for files, types, etc

I'm trying to understand what is the query format when I press (Cmd + P) or (Comd + T) and then type something.
Let's say I type ABC. it seems to me that VSCode searches using the regex A.*B.*C.*. Is it correct? It also appears that * is also allowed in the query, but I got confusing results, for example here
Can someone please point me out to the documentation about the query format?
It is called "fuzzy" matching or searching. I couldn't find any formal documentation other than something like implementing fuzzy matching. For your odd test case of vs*b it looks like they are trying to implement fuzzy matching with out-of-order symbols like some other editors have.
See also More fuzzy matching:VSCode documenation
The file picker is not using regular expressions, but a fuzzy search algorithm. I think this feature is somehow connected to IntelliSense, but I am not aware of any detailed technical documentation. However, it has been introduced in December 2015 (VSCode 0.10.6) and became a default setting in January 2016 (VSCode 0.10.9).
On GitHub you can find an issue collecting bug reports / feature requests regarding the fuzzy searching. If you want to dig much deeper into this topic, you might find a good starting point there.
As a side note, also the User Settings(File > Preferences > Settings) seem to use the same kind of fuzzy search:

How do I ignore /usr/include in Coverity Scan?

I've set up a project to use Coverity Scan.
Under Analysis Settings→Project Components I have
Component name Pattern Ignore in analysis
cxxopts .*/src/cxxopts.hpp Yes
STL /usr/include/c++/.* Yes
but still when I go to View defects I see 9 issues, all from files like /usr/include/c++/5.4.1/functional. How do I actually exclude them?
Confusingly, the Overview tab shows
12 Total defects
2 Outstanding
7 Dismissed
3 Fixed
even though View defects shows 9 issues (is that the 7+2? Why are some outstanding and some dismissed, when all should be ignored?)
It looks like a regex pattern, in which case the "++" likely needs some form of escaping. I'm not sure which form, because I don't know how the strings are being interpreted or what kind of regex syntax is being used, but some variant of the following should work:
/usr/include/c\+\+/.*
/usr/include/c\\+\\+/.*
/usr/include/c\\\+\\\+/.*
If none of these work, I'd suggest contacting scan-admin#coverity.com (listed as the contact email for questions on the scan website).
This would also explain why the overview shows results from these files at all.

Can anyone explain the syntax error in this trivial SlamData SELECT statement?

I have the following select statement:
select * from '/MOUNT_NAME/DB_NAME/TABLE_NAME'
Where MOUNT_NAME, DB_NAME, TABLE_NAME are just what they say they are.
The above syntax works just fine in the generated SQL statement when first opening a notebook and exploring the data. However, when I type in the same thing in a SQL window created in that notebook I get the following error:
operator '(' expected; '/MOUNT_NAME/DB_NAME/TABLE_NAME'
Any suggestions? Am I misusing the Notebook behavior for writing just simple syntax? Must be doing something wrong since this seems so straightforward. Any clarification out there?
The correct query would be:
SELECT * FROM `/MOUNT_NAME/DB_NAME/TABLE_NAME`
Note the use of back-ticks (not single quotes) to escape identifiers, which changed recently when SlamData was updated to use the latest version of Quasar. It looks like not all documentation on the SlamData website has been updated yet.

What's so great about Block Selection Mode?

Longtime Eclipse user here; I recently discovered the "Block Selection Mode" (Alt-Shift-A) that was added into Eclipse 3.5. I tried it out, it's pretty neat--I can select a rectangle of text in my source code instead of selecting things a line at a time like I usually do.
Apparently this feature is common in other editors too, under other names like "column edit mode", etc. A lot of people seem to really love it, but I've got by without for a long time.
So my question is: What kinds of things is this feature useful for?
The only one I can think of is inserting a comment characters (like // or #) in front of a chunk of text. Also, I supposed if I had a bunch of variables names that were all lined up and I wanted to change the first characters for all of them at once. But surely there's more to it than that? I mean, when it comes to choosing an editor, this feature is apparently a deal-breaker for some people!
I find it is very useful when working with fixed-position field data files, and you only want to select a few fields for search-replace or copy-paste. It is also good for things like this:
call_foo('A',123);
call_foo('B',143);
call_foo('C',331);
call_foo('A',113);
call_foo('R',789);
The code is all the same except for some characters in some columns. You could select a block around the second parameter and search for the line containing 113. Useful when you have more than just a few lines all together in this format.
A colleague of mine told me of a project where they wrote JDBC code like this:
String query =
"select question, answer, accepted " +
"from so_answers " +
"where poster = 'Jon Skeet' " +
"order by upvotes ";
So that they could block-select the SQL in order to paste it into a database tool and run it by hand. Seems a bit barmy to me, but it evidently worked for them.
If you arn't using a block cut/copy/paste operation at least four or five times a day then I would suggest you're just doing a lot of extra typing.
If you are looking at a file with fixed width fields, sometimes you only want to select one column.