Horton

Thread

  1. ILIKE

    Peter Eisentraut <peter_e@gmx.net> — 2003-02-22T00:36:43Z

    AFAICT, ILIKE cannot use an index.  So why does ILIKE even exist, when
lower(expr) LIKE 'foo' provides a solution that can use an index and is
more standard, too?

-- 
Peter Eisentraut   peter_e@gmx.net

  2. Re: ILIKE

    Mark Woodward <pgsql@mohawksoft.com> — 2003-02-22T15:56:00Z

    I am not familiar with ILIKE, but I suspect that if people are moving 
from a platfrom on which it exists, or even creatingmulti-platform 
applications, there may be a substancial amount of code that may use it.

Peter Eisentraut wrote:

>AFAICT, ILIKE cannot use an index.  So why does ILIKE even exist, when
>lower(expr) LIKE 'foo' provides a solution that can use an index and is
>more standard, too?
>
>  
>

  3. Re: ILIKE

    Vince Vielhaber <vev@michvhf.com> — 2003-02-22T15:57:14Z

    On Sat, 22 Feb 2003, mlw wrote:

> I am not familiar with ILIKE, but I suspect that if people are moving
> from a platfrom on which it exists, or even creatingmulti-platform
> applications, there may be a substancial amount of code that may use it.

I don't know about other platforms but I've been using it in scripts for
a couple of years.

Vince.
-- 
 Fast, inexpensive internet service 56k and beyond!  http://www.pop4.net/
   http://www.meanstreamradio.com       http://www.unknown-artists.com
         Internet radio: It's not file sharing, it's just radio.

  4. Re: ILIKE

    Peter Eisentraut <peter_e@gmx.net> — 2003-02-23T01:38:39Z

    mlw writes:

> I am not familiar with ILIKE, but I suspect that if people are moving
> from a platfrom on which it exists, or even creatingmulti-platform
> applications, there may be a substancial amount of code that may use it.

But there are no other systems on which it exists.

-- 
Peter Eisentraut   peter_e@gmx.net

  5. Re: ILIKE

    scott.marlowe <scott.marlowe@ihs.com> — 2003-02-24T16:34:14Z

    On Sat, 22 Feb 2003, Peter Eisentraut wrote:

> AFAICT, ILIKE cannot use an index.  So why does ILIKE even exist, when
> lower(expr) LIKE 'foo' provides a solution that can use an index and is
> more standard, too?

I would guess because for lower(expr) to work you need to make an index on 
it.  Since making ilike work invisibly would require the creation of an 
"invisible" lower(expr) index, it would double index storage requirements 
without warning the user.

To make ilike invisible it might be worth setting up a GUC that controls 
automatic ilike index creation.  That way ilike could either be a seq scan 
all the time function, which is great for certain operations anyway, or
an automatically indexed operation.  

#create_ilike_indexes = false  # costs 2x storage on index of text, char, 
types

I like ilike, but it's seq scan nature is a bit klunky.

  6. Re: ILIKE

    Mark Woodward <pgsql@mohawksoft.com> — 2003-02-25T13:13:27Z

    I don't understand why you would want to remove a working feature. Even 
if they are features which you do not like, why remove them? One of the 
things about the PostgreSQL core team that troubles me is a fairly 
arbitrary feature selection process.

It seems a feature has to be "liked" by someone for inclusion. I am 
often taken by surprise by how you guys judge what the PostgreSQL 
usership wants or "needs" based on your own perspective, and if someone 
uses it differently, the reaction is fierce resistance.

The issue seems to be that there is some sort of feature phobia. Why 
remove "ILIKE?" Why not just document an alternative for higher 
performance?  Why can't you guys allow features even though you don't 
necessarily agree? Yes, absolutely, assure the quality and accuracy of 
the feature, but just ease up on the resistance. Allow things even 
though you don't see the usefulness. Keep features even though you don't 
agree with them.

One of the benefits of open source is the inclusiveness of contribution. 
The plurality of development. The ability to harness the experience and 
work of people around the world.  People with different objectives and 
perspectives than yours.

In Open Source, the attitude should not be "do we want this feature?" 
but "can we add/keep this without affecting anything else?" The first 
argument is based on the assumption you know what everyone wants or 
needs, which is preposterous, the second argument is based on how well 
you know the PostgreSQL code and structure, which is a far more 
reasonable position.

  7. Re: ILIKE

    Andrew Sullivan <andrew@libertyrms.info> — 2003-02-25T13:29:38Z

    On Tue, Feb 25, 2003 at 08:13:27AM -0500, mlw wrote:

> things about the PostgreSQL core team that troubles me is a fairly 
> arbitrary feature selection process.

[. . .]

> In Open Source, the attitude should not be "do we want this feature?" 
> but "can we add/keep this without affecting anything else?" The first 

I can't think of an actual case where PostgreSQL dropped a feature
without the latter question being the one which was answered.  Note
that one possible value of "anything else" in that question is
"ability to work on something else instead of maintaining this code". 
Sometimes features get dropped because no-one is interested in
maintaining them (where "interest" is measured as a function of
willingness to do the maintenance on the code), and the cost of
maintaining them is great enough that it's a distraction.

That said, it seems to me even the latter case is pretty rare.  What
case were you thinking of?  (Surely this one doesn't qualify as an
example: it's apparent that the suggestion to remove ILIKE has caused
plenty of opposition.)

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110

  8. Re: ILIKE

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-03-06T16:06:57Z

    I can comment on this --- adding a feature isn't zero cost.  There is
maintenance, but the larger cost is of users wading through features to
figure out if they need it or not.  We don't want to bloat ourselves to
the point PostgreSQL becomes harder to use.

Let's face it, you have to understand a feature before you can decide if
it useful to you.  Adding a feature that is of limited usefulness pushes
that analysis on every PostgreSQL users studying the PostgreSQL feature
set.

---------------------------------------------------------------------------

mlw wrote:
> I don't understand why you would want to remove a working feature. Even 
> if they are features which you do not like, why remove them? One of the 
> things about the PostgreSQL core team that troubles me is a fairly 
> arbitrary feature selection process.
> 
> It seems a feature has to be "liked" by someone for inclusion. I am 
> often taken by surprise by how you guys judge what the PostgreSQL 
> usership wants or "needs" based on your own perspective, and if someone 
> uses it differently, the reaction is fierce resistance.
> 
> The issue seems to be that there is some sort of feature phobia. Why 
> remove "ILIKE?" Why not just document an alternative for higher 
> performance?  Why can't you guys allow features even though you don't 
> necessarily agree? Yes, absolutely, assure the quality and accuracy of 
> the feature, but just ease up on the resistance. Allow things even 
> though you don't see the usefulness. Keep features even though you don't 
> agree with them.
> 
> One of the benefits of open source is the inclusiveness of contribution. 
> The plurality of development. The ability to harness the experience and 
> work of people around the world.  People with different objectives and 
> perspectives than yours.
> 
> In Open Source, the attitude should not be "do we want this feature?" 
> but "can we add/keep this without affecting anything else?" The first 
> argument is based on the assumption you know what everyone wants or 
> needs, which is preposterous, the second argument is based on how well 
> you know the PostgreSQL code and structure, which is a far more 
> reasonable position.
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073