Date: Mon, 15 Aug 2005 18:43:49 -0600
From: Michael Fuhr <mike@fuhr.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Sebastian Siewior <lavish@kamp-dsl.de>, pgsql-sql@postgresql.org
Subject: Re: Problem with a Pettern Matching Check
Message-ID: <20050816004349.GA71850@winnie.fuhr.org>
References: <20050816001950.2225e5b8@mikejones.ghb.fh-furtwangen.de>
	<20050815224208.GA51332@winnie.fuhr.org>
	<18684.1124151683@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <18684.1124151683@sss.pgh.pa.us>

On Mon, Aug 15, 2005 at 08:21:23PM -0400, Tom Lane wrote:
> Michael Fuhr <mike@fuhr.org> writes:
> > The CHAR(3) specification causes the value to be space-padded, so
> > '1' becomes '1  ' (the digit "one" followed by two spaces).
> 
> Actually, we seem to be going out of our way to make this case fail.
> 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?
I notice that equality and SQL regular expressions treat trailing
spaces differently -- is that intentional or accidental?

CREATE TABLE foo (test char(3));
INSERT INTO foo VALUES ('1');

SELECT test, test = '1', test SIMILAR TO '1' FROM foo;
 test | ?column? | ?column? 
------+----------+----------
 1    | t        | f
(1 row)

SELECT test, test = '1  ', test SIMILAR TO '1  ' FROM foo;
 test | ?column? | ?column? 
------+----------+----------
 1    | t        | t
(1 row)

> That would happen automatically if we allowed
> the char(n) value to promote to text --- and the only reason it's
> not doing so is that there's an extra ~ operator definition that
> specifically prevents that (bpcharregexeq).

"bpcharregexeq" -- didn't Philip Glass write the score to that?

-- 
Michael Fuhr