/exp HTTP endpoint confusing reports

[bluestreak01]

Describe the bug

1. create table weather
2. execute the following to attempt to drop it

curl -G --data-urlencode \    "query=drop table weather" \
    http://localhost:9000/exp

Observe response to be:

• json rather than text
• response leads you to believe drop cannot be executed

"query":"drop table weather","error":"/exp endpoint only accepts SELECT","position":0}

3. list tables and observe that table has been actually deleted

To reproduce

No response

Expected Behavior

No response

Environment

- **QuestDB version**:
- **OS**:
- **Browser**:

Additional context

No response

[Belair34]

What is the expected behavior? Should it prevent the drop, or just allow it and avoid the misleading error message?

[bluestreak01]

hey @Belair34 it is better late than never to reply! Sorry for the delay!

This endpoint is meant to be read only. So it if it is SQL that is not supposed to be run via this endpoint it should not run at all.

Right now, and it is a guess, the code uses type of SQL after SQL was compiled. Which is too later for alter table that executes during compilation.

A full blown "correct" solution would be to have "compile" stage produce model and then execute them separately. But for things like alter this seemed an overkill at the time.

Perhaps we can introduce an attribute on SqlExecutionContext, which would help execution sites decide if to execute SQLs or not.

Feel free to explore the codebase and perhaps see what works best.