Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / Informix Topics / November 2007

Tip: Looking for answers? Try searching our database.

Why doesn't Informix support the simple position(str, str) returning     int function?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
bozon - 28 Nov 2007 16:57 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?
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.
bozon - 28 Nov 2007 17:02 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 - 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.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.