X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 91B8D52811
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Mon, 15 Aug 2005 22:15:05 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 87627-09
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Tue, 16 Aug 2005 01:15:02 +0000 (GMT)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by svr1.postgresql.org (Postfix) with ESMTP id 3883E5280F
	for <pgsql-sql@postgresql.org>; Mon, 15 Aug 2005 22:14:58 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j7G1EwLR019852;
	Mon, 15 Aug 2005 21:14:58 -0400 (EDT)
To: Michael Fuhr <mike@fuhr.org>
Cc: Sebastian Siewior <lavish@kamp-dsl.de>, pgsql-sql@postgresql.org
Subject: Re: Problem with a Pettern Matching Check 
In-reply-to: <20050816004349.GA71850@winnie.fuhr.org> 
References: <20050816001950.2225e5b8@mikejones.ghb.fh-furtwangen.de>
	<20050815224208.GA51332@winnie.fuhr.org>
	<18684.1124151683@sss.pgh.pa.us>
	<20050816004349.GA71850@winnie.fuhr.org>
Comments: In-reply-to Michael Fuhr <mike@fuhr.org>
	message dated "Mon, 15 Aug 2005 18:43:49 -0600"
Date: Mon, 15 Aug 2005 21:14:58 -0400
Message-ID: <19851.1124154898@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006]
X-Spam-Level: 
X-Archive-Number: 200508/108
X-Sequence-Number: 22336

Michael Fuhr <mike@fuhr.org> writes:
> On Mon, Aug 15, 2005 at 08:21:23PM -0400, Tom Lane wrote:
>> Given that we consider trailing spaces in char(n) to be semantically
>> insignificant, would it make sense to strip them before doing the
>> regex pattern match?

> How standards-compliant would that be?  Does the standard specify
> what should happen when using SIMILAR TO with a char(n) value?

Hmm ... suddenly I'm getting a strong sense of deja vu ... think we've
been around this merry-go-round before.  SQL99 says

             ii) The <predicate>

                   MC LIKE PC

                 is true if there exists a partitioning of MCV into
                 substrings such that:

                 1) A substring of MCV is a sequence of 0 (zero) or more
                   contiguous <character representation>s of MCV and each
                   <character representation> of MCV is part of exactly one
                   substring.

                 2) If the i-th substring specifier of PCV is an arbitrary
                   character specifier, the i-th substring of MCV is any
                   single <character representation>.

                 3) If the i-th substring specifier of PCV is an arbitrary
                   string specifier, then the i-th substring of MCV
                   is any sequence of 0 (zero) or more <character
                   representation>s.

                 4) If the i-th substring specifier of PCV is neither an
                   arbitrary character specifier nor an arbitrary string
                   specifier, then the i-th substring of MCV is equal to
                   that substring specifier according to the collating
                   sequence of the <like predicate>, without the appending
                   of <space> characters to MCV, and has the same length as
                   that substring specifier.

                 5) The number of substrings of MCV is equal to the number
                   of substring specifiers of PCV.

Rule ii.4 says that you use the collating sequence associated with the
data values, which is where the SQL spec keeps its space sensitivity
information --- but the restrictions about not adding space characters
and having the same length seem to be intended to prevent use of
pad-space-insensitivity to create a match.

I think we read this text before, came to the same conclusion, and
put in the special operator to make it behave that way.  So ...
never mind.

			regards, tom lane