an index being set up to provide multi column sort functionality failed to provide a consistent sort result with the second sort criteria. see the attached file 01.sql.
removing all the unecessary whitespace characters from the parameter list of the index create statement (see bug 3317784) as well as from the lcontains sort directive changed the select result to:
OWNER |NAME
------------------------------|------------------------------
CTXSYS |CTX_DDL
CTXSYS |DRIG
CTXSYS |DRIG
CTXSYS |DRVDDL
DBSNMP |DM_FMTLIB
HUGO |DBA_UTL_SPFILE
HUGO |FPBENUTZ
HUGO |FPBENUTZ
HUGO |FPBROOM
HUGO |FPBUTL
will is probably the correct and expected result.
however, this finding does in fact endorces my request to rework the parser code of ldi, for the parameters of a create or alter or the directives of lcontains (and whatever else will be parsed also. this parsing behaviour traps the developer in a very poor and unattractive way and does not promote an enployment of ldi.
p
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
repro example
hi,
removing all the unecessary whitespace characters from the parameter list of the index create statement (see bug 3317784) as well as from the lcontains sort directive changed the select result to:
OWNER |NAME
------------------------------|------------------------------
CTXSYS |CTX_DDL
CTXSYS |DRIG
CTXSYS |DRIG
CTXSYS |DRVDDL
DBSNMP |DM_FMTLIB
HUGO |DBA_UTL_SPFILE
HUGO |FPBENUTZ
HUGO |FPBENUTZ
HUGO |FPBROOM
HUGO |FPBUTL
will is probably the correct and expected result.
however, this finding does in fact endorces my request to rework the parser code of ldi, for the parameters of a create or alter or the directives of lcontains (and whatever else will be parsed also. this parsing behaviour traps the developer in a very poor and unattractive way and does not promote an enployment of ldi.
p