DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=NPE6xqdR6K9C5MFV+GfLjp3dJe8Uhzp3H5360feRw4iXXZvgzVhB95wqCjeqEG/MclvDRJMc331JM9DbczmJ6hTFdgPbcwxa0IXyqI9tWqVPE1Tbtsu0ijZUM6VIodBRqtgXscXlOWRNm1HBkv2eJdVxznfDR4+7fp2+v3LFb3s=
Message-ID: <acc274b30709040838s31410a71x149b2e87f9590db2@mail.gmail.com>
Date: Tue, 4 Sep 2007 08:38:28 -0700
From: "Ben Tilly" <btilly@gmail.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Subject: Re: tsearch filenames unlikes special symbols and numbers
Cc: "Pavel Stehule" <pavel.stehule@gmail.com>,
	"Alvaro Herrera" <alvherre@commandprompt.com>,
	"Gregory Stark" <stark@enterprisedb.com>,
	"Oleg Bartunov" <oleg@sai.msu.su>,
	"PostgreSQL Hackers" <pgsql-hackers@postgresql.org>
In-Reply-To: <23999.1188913981@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <162867790709021328i7771aa9jfe79268bccbf123d@mail.gmail.com>
	<18259.1188773171@sss.pgh.pa.us> <87y7foir7t.fsf@oxford.xeocode.com>
	<19257.1188777110@sss.pgh.pa.us>
	<20070903190302.GD10282@alvh.no-ip.org>
	<24214.1188846905@sss.pgh.pa.us>
	<acc274b30709031650i5b10de96se8168c6ea27a1a4f@mail.gmail.com>
	<5404.1188864206@sss.pgh.pa.us>
	<162867790709032204m1895d36ci78de7d4f4e759655@mail.gmail.com>
	<23999.1188913981@sss.pgh.pa.us>

On 9/4/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
[...]
> But on further thought it strikes me that insisting on all lower case
> doesn't eliminate case-sensitivity portability problems.  For instance,
> suppose the given parameter is 'foo' and the actual file name is
> Foo.dict.  This will work fine on Windows and will stop working when
> moved to Unix.  So I'm not sure we really buy much by rejecting
> upper-case letters in the parameter --- all we do is constrain which
> side of the fence you have to fix any mismatches on.  And we picked the
> side that only a DBA, rather than a plain SQL user, can fix.

True, only a DBA can fix it.  But only a DBA can screw it up.  That
seems reasonable to me.  Furthermore fixing this mistake at the plain
SQL user level in reality means auditing a code base for the
construct, which is never fun.

However if you wish to be paranoid, I believe that all filesystems of
interest to PostgreSQL are at least case preserving.  In which case on
case sensitive filesystems you could check that the case of the stored
filename matches what you want it to be.  Now the problem of the
filename having the case wrong can be detected on both Windows and
Unix.

Of course that check is a complication and slows things down.  If all
dictionary files have to be in a fixed directory, then you can easily
add a cron job that scans that directory and fixes the case of any
dictionary files that have upper case letters in their names.
(Beware, there was once a bug in Windows where renaming Foo to foo
accidentally deleted the file.  It is therefore safer to rename Foo to
bar then bar to foo.  However this is a moot point since I doubt that
anyone would actually run a brand new PostgreSQL database on an early
version of NT 4.0...)

Cheers,
Ben