I can run the following statement just fine
select json_transform('[1,2,3]', append '$' = 4) from dual;
But Toad tells me it's wrong and I can not format it.
Currently using Toad 24.2.275.4664 and Oracle database 19c.
Btw, a related question, was an escape hatch ever added to Toad for formatting or error checking? E.g. a specific comment for Toad to disregard code that could be used in these cases where Toad is not up to date. I was told it had been planned here but since that trick still works I assume it was never implemented. Would be useful both for PL/SQL and regular SQL. Might be a good idea to have a separate one for error checking and auto formatting, maybe even an "I know what I'm doing" hint for the rule engine.
Similar issue Realtime syntax checker incorrect - v17.1, Oracle 19.20
Queued as QP-4319.
Thanks for reporting,
Andre (aka Andreas in the region where I'm living 
)
Hello Andreas,
Json_transform() syntax has been added and will be available whenever Toad includes QP5.dll version 5.422 (or higher), soon.
As to the "escape hatch", I walked over the links in your post again. I feel that we must keep things as simple as possible.
First of all, we as parser team have to have our own house in order and make sure that grammar is up to date as quickly as possible. This year we'll have more resources to achieve that goal. So we won't work on tricks to disable syntax checking of individual statements, that would not be needed.
As to formatting, the request to skip formatting / not touch formatting of individual statement arises at times. It is a technically feasible thing to do, and it is simple to understand. I'm thinking of a user settable comment (or string to be found in a comment) to be inserted just before the statement. Then we can forget about that $if true/false hacking altogether.
Does this makes sense as a new year's intention?
Thanks,
Andreas
Ok, thanks. Yes, if you can at least still use the autoformat even when there is features not yet implemented than it would be easier to live with Toad complaining about errors until it has been implemented.
So that should be the most useful of the two "escape hatches" as it can help both with that and when you just want to do some manual formatting. This assumes that the auto formatter would skip past both custom formatting and things considered incorrect code by the parser if inside the "escape hatch".
One thing though, "inserted just before the statement" it could at times be a bit annoying if you meant that you need a comment before each line rather than having an option for a start and end string so you can use it for en entire section of code/sql. So personally I would have implemented it as something like:
/*<!!*/
No autofomat here
/*!!>*/
Not sure if useful but if the string is short and works in block comments this feature could possible be useful for just part of a line of code as well. Of course you could do both as well since a single comment would be more convenient in those cases where you only need it for a single line.
Yes indeed, I was thinking of one comment for a single statement and another pair of comments (on-off) for a block ... Either could be -- or /*...*/ style.
1 Like