The query you were running (with a minor syntax error, hence the error message) is what we call a “Built-in Query”: https://docs.tigergraph.com/start/gsql-examples/common-applications#built-in-queries
Built-in Queries are not GSQL; they are very SQL-like, but also limited in capability. They provide a handy way to select and inspect the vertices and edges that are in the database. They are not for graph traversal or analytics or transactions.
The specific error: You can only select edges if you specific a single source vertex using the clause WHERE from_id==<source_id>
Note, however, that running built-in queries is unrelated to whether you are in the GSQL interactive console or not. For example, if you in a Linux shell, you can run a built-in query the same way you would run a GSQL command, but enclosing it in quotes (or by naming a file containing your commands).
The concept of “Built-In” query is confusing to me…
It’s not mentioned in the documentation built-in-queries how they are special and “not GSQL even though they are SQL-like”… I had the impression that GSQL is SQL-like (from the marketing materials), but now I see that’s not true but I’m failing to understand the differences.
The error message is also not helpful. (Thankfully, when I searched for it, I got this page.). Perhaps you can put in an example of what’s expected? Since there are at least two people who were puzzled by this, a better error message is warranted.
If you’re used to SQL, then the fact that this works:
select COUNT(*) from person-(friendship)-person
and this doesn’t:
select * from person-(friendship)-person limit 3
is deeply disturbing in that it breaks the paradigm I have in my mind about how SQL-like languages should work.
Worse, when I accidently use a Built-in Query without realizing and it works, then I’m getting positive reinforcement for a paradigm that is incorrect.
Clearly, there’s something afoot here in TigerGraph land that I (a noob) haven’t uncovered in the documentation yet. Is there a page that explains this?
Thanks.
[added]
Maybe the “Semantic Check” error message should say something more along the lines that this is not a “built-in query” and you need to reformulate the query as a “non-built-in query” (or whatever the proper phraseology is.)
Is the bottomline that I need to provide a lot more boilerplate code in order to untap the full power of GSQL?
They are a remnant of some early work that was done before GSQL was introduced.
They are handy for checking how many vertices you have, or to do a spot check of some data you inserted.
There is no plan to ever expand upon them; we are more likely to drop them when we add more syntax sugar to GSQL so that writing ad hoc GSQL queries by hand is even more streamlined.