Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 4D2AF9FA099 for ; Tue, 4 Sep 2007 12:18:20 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 20182-01-10 for ; Tue, 4 Sep 2007 12:17:59 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by postgresql.org (Postfix) with ESMTP id E33F69FA0B2 for ; Tue, 4 Sep 2007 12:18:16 -0300 (ADT) Received: by wx-out-0506.google.com with SMTP id r21so1677657wxc for ; Tue, 04 Sep 2007 08:18:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jeHf/NfzM5BshUJTcUXfTx/3aGvXlJFZktLKkfPVTp5ifK1yaFrEAh23ZzaiTst1HLWgbUIxyl/jM5X72acOSkTN7wQbEJPMKxD3u4y7fRKF06dBUe+UlsrQF/Qac2jugqENiW83xyoktROzyYRH8Vv9RdICGoZgmL7DyTkknko= 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=bx/UwwEG8g0UUCYaMgASH7AHWnjl6keePQF+eI/F7BGVoww7AVBuIEmPWvvO3EbNEAMnpJTb+GxYo6MamQsKqaeeos+YxpdBVKHuMcT/3E3tKfQtJAnfKJ69DdAkAN5lfjfL0qLSsOwiBVA4m11ZCJie71DDOrcSQBcsc/ZLHCk= Received: by 10.90.34.3 with SMTP id h3mr5525736agh.1188919096133; Tue, 04 Sep 2007 08:18:16 -0700 (PDT) Received: by 10.90.34.18 with HTTP; Tue, 4 Sep 2007 08:18:16 -0700 (PDT) Message-ID: <162867790709040818w6ca6d30fi3f9b18db45b86dac@mail.gmail.com> Date: Tue, 4 Sep 2007 17:18:16 +0200 From: "Pavel Stehule" To: "Tom Lane" Subject: Re: tsearch filenames unlikes special symbols and numbers Cc: "Ben Tilly" , "Alvaro Herrera" , "Gregory Stark" , "Oleg Bartunov" , "PostgreSQL Hackers" In-Reply-To: <23999.1188913981@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 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> <5404.1188864206@sss.pgh.pa.us> <162867790709032204m1895d36ci78de7d4f4e759655@mail.gmail.com> <23999.1188913981@sss.pgh.pa.us> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200709/144 X-Sequence-Number: 107296 2007/9/4, Tom Lane : > "Pavel Stehule" writes: > > 2007/9/4, Tom Lane : > >> Yeah, good point. So far it seems that a-z 0-9 and underscore cover the > >> real use-cases, so what say we just allow those for now? It's a lot > >> easier to loosen up later than tighten up ... > > > It's system specific. I prefere a-z and A-Z. Clasic name for > > dictionaries combine lower and upper characters .. for czech > > cs_CZ_UTF8 etc. > > You're going to need to alter that habit anyway, because it's not > appropriate to mention any specific encoding in the dictionary name. > > 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. > ok. I can understand it. But I don't see sense of quoting of params Regards Pavel Stehule