From: | will trillich <will(at)serensoft(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Hope it is not too offtopic |
Date: | 2001-03-22 18:36:29 |
Message-ID: | 20010322123629.A10503@mail.serensoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Mar 21, 2001 at 08:03:47PM +0100, Jan Ploski wrote:
> > I have a database of ISO standards ... my clients want to be able to do a
> > full document search ... but it's not a document ... it's a database
> > Is there a way (more likely a query question) to
> > select * from tablename where <anyfield> like '%term%'??
>
> This query will work, but I suspect this is a very inefficient way
> of doing a full text search.
not literally, it wouldn't:
select * from tbl where <oops> like '%pat%';
--ERROR: parser: parse error at or near "<"
i think the question was intended to ask if it's possible to
specify that postgres search EVERY field for a pattern, INSTEAD of
a PARTICULAR field for a pattern:
-- i.e. rather than the tedious (and workable):
select * from tbl
where fld01 like '%term%'
or fld02 like '%term%'
or fld03 like '%term%'
or fld04 like '%term%'
or fld05 like '%term%'
or fld06 like '%term%'
or fld07 like '%term%'
or fld08 like '%term%'
or fld09 like '%term%'
or fld10 like '%term%'
or fld11 like '%term%'
;
-- hopes were high for something like this instead:
select * from tbl
where * like '%term%'
;
-- or maybe this:
select * from tbl
where (fld02 | fld15 | fld42) like '%term%'
;
which <guess confidence=purty-darn-high> i'd bet isn't even on
the 'to-do' list. </guess>
<guess confidence=not-very-low> probably, what is needed,
instead, is a re-structuring of the database. </guess>
--
case in point: i had some lookup tables such as
create table l_menu (
id varchar(5),
other varchar(50),
en varchar(50), -- english description of this menu
es varchar(50), -- espanol description of this menu
fr varchar(50), -- francais description of this menu
de varchar(50), -- deutsch description of this menu
primary key(id)
);
so that in perl, i could
$sth = $dbh->prepare(<<SQL);
select other,$LANG
from l_menu
...yadayada...
SQL
but i eventually ran into logistical snags, so now i've got
create table l_menu (
id varchar(5),
other varchar(50),
primary key(id)
);
create table d_menu (
id varchar(5) references l_menu(id),
lang varchar(5),
descr varchar(50),
primary key(id)
);
which is still reasonably easy to work with, in perl:
$sth = $dbh->prepare(<<SQL);
select other,descr
from l_menu,d_menu
where l_menu.id=d_menu.id and d_menu.lang='$LANG'
...yadayada...
SQL
except now it's easier to munge on the database end -- for
example, to add new languages.
--
relating it to this thread (i had to get around to this
eventually :) imagine if i was looking for a description in any
language that contained 'xyz':
select id from l_menu
where en like '%xyz%'
or es like '%xyz%'
or fr like '%xyz%'
or de like '%xyz%';
-- ick! (old snanky style)
contrast with
select distinct l_menu.id from l_menu,d_menu
-- or, "select l_menu.id,lang from l_menu,d_menu"
where descr contains '%xyz%'
and l_menu.id = d_menu.id;
-- yummy! (new chrome-plated dual-exhaust high-octane style)
--
It is always hazardous to ask "Why?" in science, but it is often
interesting to do so just the same.
-- Isaac Asimov, 'The Genetic Code'
will(at)serensoft(dot)com
http://newbieDoc.sourceforge.net/ -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
From | Date | Subject | |
---|---|---|---|
Next Message | will trillich | 2001-03-22 18:42:12 | Re: error messages VERY misleading...! |
Previous Message | pgh | 2001-03-22 18:03:53 | question?????? |