Skip to Main Content

Database Software

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

more automatic query expansions to use available function based index (e.g. UPPER,DECODE)

Rainer StenzelDec 10 2014 — edited May 4 2018

I would really like to see the query expansion already implemented for TRUNC and SUBSTR applied more commen e.g. for UPPER and DECODE (for better support of "partial" indexes as already outlined in the DECODE use case below).

Index on trunc(date) – do you still need old index?

Index on SUBSTR(string,1,n) – do you still need old index?/

original idea:

A query has an equality predicate eq(t.c,constant_expression) on column t.c and table t has a function based index f(t.c).

Shoudn't it then be possible to add a predicate eq(f(t.c),f(constant_expression)) to the query to enable additional access pathes via index f(t.c) ?

Example:

With index

create index upper_DEPARTMENT_NAME on DEPARTMENTS (upper(DEPARTMENT_NAME));

queries with a predicate

... from ... DEPARTMENTS ... where ... DEPARTMENT_NAME=:b1 ...

should be rewritten to and optimized with

... from ... DEPARTMENTS ... where ... (DEPARTMENT_NAME=:b1 AND upper(DEPARTMENT_NAME)=upper(:b1)) ...

to enable the INDEX RANGE SCAN access path via index upper_DEPARTMENT_NAME.

B.t.w. nice terms of use for new ideas (at least for Oracle).

Comments

Gaz in Oz

This is likely more of a ubuntu issue than a sqlcl isue.

. Do the <TAB> key and cursor keys behave as expected in the shell (BEFORE starting sqlcl)?

. What shell are you in/using?

  $  echo $SHELL

bash will be the most likely shell to behave "properly" with no changes on your part.

If it is not bash, you can change it by:

  $ sudo chsh -s /bin/bash <username>

. Does the <TAB> and the cursor keys behave as expected in the shell now?

          up/down should show previous/next commands you've executed in this shell. <TAB> is auto-complete/show files in current directory.

If that's working, try starting sqlcl "now" and see how you go.

If that doesn't fix your keys, then perhaps other answers here may help:

https://askubuntu.com/questions/325807/arrow-keys-home-end-tab-complete-keys-not-working-in-shell

User_E4DJL

I figured it out finally via strace: SQLcl uses the readline library and reads ~/.inputrc. In particular SQLcl doesn't cope with assigning "menu-complete" to the Tab key and history-search-backward/history-search-forward to the cursor keys. I tried setting $INPUTRC to /dev/null for SQLcl but this didn't work. At least I know now what's going on.

Gaz in Oz

Works fine on CentOS7 and connecting to the linux server with putty, so sqlcl isn't the issue.

User_E4DJL

You need a ~/.inputrc with the following lines to demonstrate the issue:

"\t": menu-complete

"\eOA": history-search-backward

"\eOB": history-search-forward

User_E4DJL

The cursor key code might depend on your terminal. But the "\t" should work regardless of the terminal emulator.

sql /nolog

sele<TAB>

will complete to SELECT without menu-complete set and will do nothing with menu-complete set.

Kelly Clowers

Would be really nice to get a bug fix for this. Confirm that if
"\eOA": history-search-backward
"\eOB": history-search-forward
(or the VT220 equivalents, "\e[A" and "\e[B")
are set in .inputrc, history access in sqlcl does not work with up and down arrows
Those bindings allow context sensitive history in e.g. Bash - ls [up] will go to the previous command that started with ls
I don't necessarily need the sqlcl history to be context sensitive, I just need the arrow keys to still work at all.

A workaround could be to use a shell script wrapper that does
bind -r "\e[A"; bind -r "\e[B"
before invoking sqlcl, this unbinds the up and down arrows and then they work in sqlcl (or the eOA eOB versions if that is what you use)

1 - 6

Post Details

Added on Dec 10 2014
11 comments
1,048 views