Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] SQL92

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: "Jackson, DeJuan" <djackson(at)cpsgroup(dot)com>
Cc: PostgreSQL Hackers Mailing List <pgsql-hackers(at)hub(dot)org>
Subject: Re: [HACKERS] SQL92
Date: 1998-09-30 01:47:15
Message-ID: 36118DA3.AFF74954@alumni.caltech.edu (view raw or flat)
Thread:
Lists: pgsql-hackers
> Well, In all of the major Databases that I have worked with there is
> also the "[character_set]" matching operator.
> Does anybody know if the "[character_set]" stuff is part of the
> standard?

Hoping against hope, eh? afaik those are all extensions (though SQL3 has
some enhanced functionality with the SIMILAR operator). From my copy of
the second draft standard published in 1992:

<like predicate> uses the triadic operator LIKE (or the inverse,
NOT LIKE), operating on three character strings and returning
a Boolean. LIKE determines whether or not a character string
"matches" a given "pattern" (also a character string). The char-
acters '%' (percent) and '_' (underscore) have special meaning when
they occur in the pattern. The optional third argument is a charac-
ter string containing exactly one character, known as the "escape
character", for use when a percent or underscore is required in the
pattern without its special meaning.

What version of Postgres are you running? I vaguely recall some
complaints and fixes in the sort-of-recent past. Don't know if it
affected simple patterns or only more complicated stuff.

Can you send a simple

  SELECT text 'your string here' LIKE 'your pattern here';

which doesn't behave as you would expect? That would make this a bit
less theoretical...

                  - Tom

In response to

pgsql-hackers by date

Next:From: Michael MeskesDate: 1998-09-30 05:47:44
Subject: Re: Antwort: [HACKERS] ecpg parser
Previous:From: Keith ParksDate: 1998-09-29 21:22:20
Subject: Re: [HACKERS] PL/pgSQL in template1?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group