like operator bug

Started by jfaithover 26 years ago3 messagesbugs
Jump to latest
#1jfaith
jfaith@cemsys.com

Your name : Jeremy Faith
Your email address :jfaith@cemsys.com

System Configuration
---------------------
Architecture (example: Intel Pentium) :Intel Pentium

Operating System (example: Linux 2.0.26 ELF) : Linux 2.0.36

PostgreSQL version (example: PostgreSQL-6.5.1): PostgreSQL-6.5.1

Compiler used (example: gcc 2.8.0) : gcc 2.7.2.3

Please enter a FULL description of your problem:
------------------------------------------------
The percent charater(%) is not functioning correctly in arguments to the
like(~~) operator. Many matches are being missed.
Also the bug tracking system at
http://www.PostgreSQL.ORG/bugs/visitor.php3
is not functioning(I reported this like bug about 2 weeks ago slip 72 I
think).
The output I get now starts with
Warning: PostgresSQL query failed: ERROR: status: Permission denied.
in ./postgres.php3 on line 40.

Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------
create table tst(addr char(4));
insert into tst values('1000');
insert into tst values('1010');
insert into tst values('1120');
select * from tst where addr like '1%0';

produces

addr
----
1120(1 row)

where it should return all of the example rows.

If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------
In the file ./src/backend/utils/adt/like.c

The function DoMatch appears to have been optimised to return LIKE_ABORT
when
the pattern cannot be matched. However in the above instance it
incorrectly
aborts causing the like function to return FALSE. I think this could be
fixed
by changing the recursuve call from
(matched=DoMatch(text,p))!=LIKE_FALSE
to
(matched=DoMatch(text,p))==LIKE_TRUE
at the expense of some speed, there may be a more efficient solution,
but it
needs a fix.
It may be that the aborting concept is flawed.

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: jfaith (#1)
Re: [BUGS] like operator bug

jfaith <jfaith@cemsys.com> writes:

create table tst(addr char(4));
insert into tst values('1000');
insert into tst values('1010');
insert into tst values('1120');
select * from tst where addr like '1%0';
produces
addr
----
1120(1 row)
where it should return all of the example rows.

You are right. I think that's my fault :-(. Will fix it.

Also the bug tracking system at
http://www.PostgreSQL.ORG/bugs/visitor.php3
is not functioning(I reported this like bug about 2 weeks ago slip 72 I
think).

We have concluded that reporting bugs via the bugs email list is a
better approach than having people make direct entries into the bug
tracking system. Theoretically the bug tracking system is for letting
people know what the status of known bugs is ... but I'm not sure if
anyone is maintaining it very diligently :-(. The website needs to be
updated to explain that you should still submit bugs via pgsql-bugs.

regards, tom lane

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Tom Lane (#2)
Re: [BUGS] like operator bug

jfaith <jfaith@cemsys.com> writes:

create table tst(addr char(4));
insert into tst values('1000');
insert into tst values('1010');
insert into tst values('1120');
select * from tst where addr like '1%0';
produces
addr
----
1120(1 row)
where it should return all of the example rows.

I believe I have fixed this. If you need the fix before 6.5.2 is out,
line 188 in src/backend/utils/adt/like.c should return LIKE_FALSE not
LIKE_ABORT:

if (*text !='\0')
! return LIKE_ABORT;
else

if (*text !='\0')
! return LIKE_FALSE;
else

regards, tom lane

From bouncefilter Wed Sep 8 12:49:30 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id MAA64434
for pgsql-hackers@postgresql.org; Wed, 8 Sep 1999 12:49:17 -0400 (EDT)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
From: Patrick Logan <patrick@c837917-a.potlnd1.or.home.com>
Subject: Problem enabling pltcl
X-Newsgroups: comp.databases.postgresql.hackers
Reply-To: patrickdlogan@home.com
User-Agent: tin/pre-1.4-19990624 ("Dawnrazor") (UNIX) (Linux/2.2.7 (i686))
Lines: 20
Message-ID: <9swB3.16241$Hu6.6507@news.rdc1.wa.home.com>
Date: Wed, 08 Sep 1999 16:49:09 GMT
X-Complaints-To: abuse@home.net
X-Trace: news.rdc1.wa.home.com 936809349 24.0.48.139 (Wed,
08 Sep 1999 09:49:09 PDT)
Organization: @Home Network
To: pgsql-hackers@postgresql.org

I have configured, built, and installed ProsgreSQL 6.5.1 using:

--with-tcl and --with-tkconfig=<dir>

As far as I have looked, everything was built and installed without a
hitch. The pltcl library is in the right location, and /etc/ld.so.conf
lists that directory.

When I define a function using pltcl I get the following:

ERROR: Unrecognized language specified in a CREATE FUNCTION:
'pltcl'. Recognized languages are sql, C, internal and the
created procedural languages.

The docs say that pltcl is enabled if it is built with the TCL
option. What am I missing?

Thanks
--
Patrick Logan patrickdlogan@home.com

From bouncefilter Wed Sep 8 13:31:30 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA69563
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Sep 1999 13:30:30 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id NAA09960;
Wed, 8 Sep 1999 13:30:17 -0400
Message-ID: <37D69D22.8876C0C4@wgcr.org>
Date: Wed, 08 Sep 1999 13:30:10 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: patrickdlogan@home.com
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Problem enabling pltcl
References: <9swB3.16241$Hu6.6507@news.rdc1.wa.home.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Patrick Logan wrote:

ERROR: Unrecognized language specified in a CREATE FUNCTION:
'pltcl'. Recognized languages are sql, C, internal and the
created procedural languages.

The docs say that pltcl is enabled if it is built with the TCL
option. What am I missing?

CREATE LANGUAGE (command line utility 'createlang'). See the regression
test shell script (src/test/regress/regress.sh) for an example using
plpgsql. The PL's are not created and installed by default, apparently.

Lamar Owen
WGCR Internet Radio