This looks like a sql-92 standard. I know several work ways to around
this discrepancy, but nothing as nice as the actual position function?
I mean they implemented replace(str, str) for gosh sakes. You have to
implement position in some fashion to do a replace, so it isn't that
much additional work would have to be done. I mean one work around is
to do
select * from foobar where searchfield is not null and searchfield <>
"" and thissucks is not null and thissucks <> "" and
length(replace(thissucks, searchfield,"")) <> length(thissucks)
will tell you if searchfield is contained in the field thissucks. I
don't think that you can use "like" because you are comparing field to
field. instead of field to search string.
Of course if you are using this to parse a string the above method is
no good. Of course there are complicated sql ways to parse a string.
I have had 2 developers in the last week ask me for ways to implement
something that would have been made easy by using the position
function.
Am I missing an easy way to get position without writing my own stored
procedure or extension.
> This looks like a sql-92 standard. I know several work ways to around
> this discrepancy, but nothing as nice as the actual position function?
[quoted text clipped - 21 lines]
> Am I missing an easy way to get position without writing my own stored
> procedure or extension.
Man I should read this stuff first before I post it "I know several
work ways to around this" should of course read "I know several ways
to work around this".
Dyslexia is tough.
Nog - 29 Nov 2007 09:58 GMT
> > This looks like a sql-92 standard. I know several work ways to around
> > this discrepancy, but nothing as nice as the actual position function?
[quoted text clipped - 27 lines]
>
> Dyslexia is tough.
If you just want to know if one field contains at least the contents
of another then you can use;
select * from foobar
where thissucks matches "*" || trim(searchfield) || "*"
(include any NULL checking as required)
HTH
bozon - 29 Nov 2007 13:59 GMT
> > > This looks like a sql-92 standard. I know several work ways to around
> > > this discrepancy, but nothing as nice as the actual position function?
[quoted text clipped - 36 lines]
>
> HTH
Thanks, this is great. Interestingly the documentation is wrong. I
would have tried this but when I looked at the documentation it said
that
like or matches could only be used with quoted strings or a column
name it didn't mention expressions. "*" || trim(searchfield) || "*" is
clearly an expression. Someone should correct the documentation or the
code. It is page
4-6 IBM Informix Guide to SQL: Syntax
Of course this is a problem I am trying to overcome, which is to rely
on documentation and not just trying things that I think should work.
I had partially gotten over this but I think I will always be somewhat
of literalist instead of an empiricist.
I still think informix needs a position function to massage string
data.
Art S. Kagel - 29 Nov 2007 14:53 GMT
> > > > This looks like a sql-92 standard. I know several work ways to around
> > > > this discrepancy, but nothing as nice as the actual position function?
[quoted text clipped - 55 lines]
> I still think informix needs a position function to massage string
> data.
Easy enough to write. Care to build the bladelet and contribute it to
the IIUG Repository?
Art S. Kagel
bozon - 29 Nov 2007 16:59 GMT
> > > > > This looks like a sql-92 standard. I know several work ways to around
> > > > > this discrepancy, but nothing as nice as the actual position function?
[quoted text clipped - 60 lines]
>
> Art S. Kagel
Not that I can because I have never written a bladelet, but which
algorithm to use?
http://en.wikipedia.org/wiki/String_searching_algorithm
I have coded boyer-moyer before but is this appropriate? Certainly for
constants this would be particularly nice.
position('abc' in field1) you would calculate the boyer table once and
then use it. For
position(field2 in field1) you could recalculate the boyer each time
or use a hash table (configurable?) to try to cache some boyer tables.
Also would you just skip the boyer if the length of field2 was below
some value (1 or 2)?
Also, how do international characters sets impact things? I don't care
but someone might.
Paul Watson - 29 Nov 2007 18:23 GMT
[cutting]
>> Of course if you are using this to parse a string the above method is
>> no good. Of course there are complicated sql ways to parse a string.
[quoted text clipped - 5 lines]
>> Am I missing an easy way to get position without writing my own stored
>> procedure or extension.
[cutting]
Load up the regexp datablade - makes playing with strings a lot easier

Signature
Paul Watson
Tel: +1 913-400-2620
Mob: +1 913-387-7529
Web: www.oninit.com
Failure is not as frightening as regret.
If you want to improve, be content to be thought foolish and stupid.
bozon - 29 Nov 2007 20:12 GMT
> [cutting]
>
[quoted text clipped - 20 lines]
> Failure is not as frightening as regret.
> If you want to improve, be content to be thought foolish and stupid.
Nice, when we get off our current platform that we don't have a decent
compiler for, I'll look into this.
Thanks. This handles the task that I needed the position to do.