Re: tsearch filenames unlikes special symbols and numbers - Mailing list pgsql-hackers

From Ben Tilly
Subject Re: tsearch filenames unlikes special symbols and numbers
Date
Msg-id acc274b30709031650i5b10de96se8168c6ea27a1a4f@mail.gmail.com
Whole thread Raw
In response to Re: tsearch filenames unlikes special symbols and numbers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: tsearch filenames unlikes special symbols and numbers
List pgsql-hackers
On 9/3/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > On the other hand, this means the name has to be quoted if it would be
> > quoted as an SQL identifier, right?
>
> Something like that.  I wasn't planning on rejecting uppercase letters,
> though, which would be necessary if you wanted to be strict about
> matching unquoted identifiers.
>
> There seems fairly clear use-case for allowing A-Z a-z 0-9 and
> underscore (while CVS head rejects 0-9 and underscore).  There also seem
> to be good arguments for disallowing / \ : on various platforms, which
> leaves us with some other punctuation in question, as well as the whole
> matter of non-ASCII characters.  I'm not sure whether we want to touch
> the idea of non-ASCII; comments?

The problem with allowing uppercase letters is that on some
filesystems foo and Foo are the same file, and on others they are not.This may lead to obscure portability problems
wherecode worked fine
 
on Unix and then fails when the database is running on Windows.

The approach that I'd suggest is allow a very restricted subset as an
immediate solution (say a-z and 0-9), and plan to later allow
arbitrary data to be passed in, then be encoded in some way before
hitting disk.  (And later need not be much later - such encodings are
not that hard to write.)

Cheers,
Ben


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Per-function GUC settings: trickier than it looked
Next
From: "Ben Tilly"
Date:
Subject: Re: tsearch filenames unlikes special symbols and numbers