– There would need to be some activation characters like after whitespace, after
– an open paren, etc. Within strings or other identifiers would not prompt
Agreed, the rules for identifying parameters would need to be clarified
– Will this ever get in your way? By that I mean setup will take a few moments to
– do and all may be well for days or weeks, but then you run a select statement
– against a table that has a column starting with P_ and you’re prompted.
It might, but 99% of the time I’d need this feature. I’d use it multiple times
daily. Because I was thinking of this in a similar fashion to “Prompt for
Substitution variables” I was thinking we could toggle this feature on/off there.
Maybe “Enable extended Substitution variable matching”.
– We need a little more explanation
– to be sure that users are voting for what they think they are because it will
– certainly add bloat to the product for those that are uninterested.
Bloat/New Features, it’s all in the eye. Thinking in terms of Substitution
Variables, in essence I’m suggesting we could expand the set from just a colon
to a user defined set. If none were set up (which would/could be the default)
then no one would be aware of the new addition.
– What about anything else in the SQL that does not fit any of the prefixes you’ve
– specified like references to other package functions? I assume those should just
– be left intact.
That’s a good one, qualified parameters in a procedure call wouldn’t be replaced,
I guess this goes back to the rules in your first point. We would need to create
a test case which involved a complex piece of SQL and determine that the rules to
identify the parameters worked. If there are parameters that don’t match any of the
formats you’ve defined then you’ll get the same error you do now.
– For example you can explain plan
– and tune SQL that is embedded within PL/SQL. I think that there is expectation
– that you should just be able to place your caret on SQL (even in PL/SQL) and
– press CTRL+E to generate an explain plan without needing to jump through
– hoops locating the user defined variable prefix feature.
That is exactly one of my requirements, I want to be able to Explain Plan SQL
without it being within PL/SQL, indeed, I want the exact features you have
implemented within PL/SQL to be available for straight SQL. As I mentioned before,
it’s rare, and often not possible as I’m viewing code in the SB and not in MOE,
that I want to execute or explain plan SQL whilst I’m working in a package.
– It should just work.
My point exactly. It should just work, whether it’s SQL within the scope of
PL/SQL or SQL on it’s own. I can’t see why you wouldn’t want it to work either