Oleg Bartunov <[EMAIL PROTECTED]> writes:
> Oh, my god, I see we dictate extensions !
> Folk, this is too much ! Now, we dictate extensions '.dict, .affix, .stop',
> what else ?
> Does it defined by ispell template only, or it's global requirements ?
It's the callers of get_tsearch_config_filenam
On Sun, 9 Sep 2007, Oleg Bartunov wrote:
Oh, my god, I see we dictate extensions !
STATEMENT: CREATE TEXT SEARCH DICTIONARY en_ispell (
TEMPLATE = ispell,
DictFile = englishDict,
AffFile = englishAff,
StopWords = englishStop
)
On Sun, 2 Sep 2007, Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
"Tom Lane" <[EMAIL PROTECTED]> writes:
I made it reject all but latin letters, which is the same restriction
that's in place for timezone set filenames. That might be overly
strong, but we definitely have to forbid
On 9/4/07, Tom Lane <[EMAIL PROTECTED]> 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
2007/9/4, Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > 2007/9/4, Tom Lane <[EMAIL PROTECTED]>:
> >> 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 lo
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2007/9/4, Tom Lane <[EMAIL PROTECTED]>:
>> 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 s
2007/9/4, Tom Lane <[EMAIL PROTECTED]>:
> "Ben Tilly" <[EMAIL PROTECTED]> writes:
> > On 9/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> There seems fairly clear use-case for allowing A-Z a-z 0-9 and
> >> underscore (while CVS head rejects 0-9 and underscore).
>
> > The problem with allowing upper
"Ben Tilly" <[EMAIL PROTECTED]> writes:
> On 9/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> There seems fairly clear use-case for allowing A-Z a-z 0-9 and
>> underscore (while CVS head rejects 0-9 and underscore).
> The problem with allowing uppercase letters is that on some
> filesystems foo and
"Ben Tilly" <[EMAIL PROTECTED]> writes:
> I don't know what you're discussing well enough to know if this is
> relevant, but what you just said is not always true. If there is any
> way to pass arbitrary binary data into your function call, then
> someone can pass in a string with nul in it.
Not
On 9/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >> I'm not convinced that . is issue-free. On most if not all versions of
> >> Unix,
> >> you are allowed to open a directory as a file and read the filenames it
On 9/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> 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
Tom Lane wrote:
> I'm not sure whether we want to touch
> the idea of non-ASCII; comments?
Non-ASCII filenames sounds like recipe for problems to me. We don't know
what encoding the filenames are in on disk.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Alvaro Herrera <[EMAIL PROTECTED]> 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
matchi
Tom Lane escribió:
> Possibly we could allow '.' as long as we forbade /, but the other
> trouble with allowing . is that it encourages people to try to specify
> the filetype suffix (as indeed Oleg was doing). I'd prefer to keep the
> suffixes out of the SQL object definitions, with an eye to po
Trevor Talbot wrote:
On 9/3/07, Mark Mielke <[EMAIL PROTECTED]> wrote:
Tom Lane wrote:
Also, says that Windows throws an error for ":" in the filename,
which means we needn't.
Windows doesn't fail - but it can do odd things. For example, try:
C:\> echo hi >foo:bar
If one then chec
On 9/3/07, Mark Mielke <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
> > Also, says that Windows throws an error for ":" in the filename,
> > which means we needn't.
> Windows doesn't fail - but it can do odd things. For example, try:
>
> C:\> echo hi >foo:bar
>
> If one then checks the di
Tom Lane wrote:
Also, says that Windows throws an error for ":" in the filename,
which means we needn't.
Windows doesn't fail - but it can do odd things. For example, try:
C:\> echo hi >foo:bar
If one then checks the directory, one finds a "foo".
Depending on *which* API one uses,
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
On Mon, Sep 03, 2007 at 07:47:14AM +0100, Gregory Stark wrote:
Actually I think in Windows \ : and . are problems (not allowed more
than one dot in dos).
\ and : are problems.
Is : really a problem, given that the name i
"Tom Lane" <[EMAIL PROTECTED]> writes:
> It might still be a good idea to restrict the names to be SQL
> identifiers (ie, alphanumerics and underscores) for future-proofing,
> but it wasn't clear whether anyone but me thought that was a good
> argument. I'm willing to make it just be no-dir-separ
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I'm not convinced that . is issue-free. On most if not all versions of Unix,
>> you are allowed to open a directory as a file and read the filenames it
>> contains. While I don't say it'd be easy to manage that
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I'm not convinced that . is issue-free. On most if not all versions of Unix,
> you are allowed to open a directory as a file and read the filenames it
> contains. While I don't say it'd be easy to manage that through
> tsearch, there's at least a potentia
On Mon, Sep 03, 2007 at 09:27:19AM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > On Mon, Sep 03, 2007 at 07:47:14AM +0100, Gregory Stark wrote:
> >> Actually I think in Windows \ : and . are problems (not allowed more
> >> than one dot in dos).
>
> > \ and : are problems
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Mon, Sep 03, 2007 at 07:47:14AM +0100, Gregory Stark wrote:
>> Actually I think in Windows \ : and . are problems (not allowed more
>> than one dot in dos).
> \ and : are problems.
Is : really a problem, given that the name in question will be appe
On Mon, Sep 03, 2007 at 07:47:14AM +0100, Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> >> "Tom Lane" <[EMAIL PROTECTED]> writes:
> >>> I made it reject all but latin letters, which is the same restriction
> >>> that's in place for
On 9/2/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> Right, traditionally the only characters forbidden in filenames in Unix are /
> and nul. If we want the files to play nice in Gnome etc then we should
> restrict them to ascii since we don't know what encoding the gui expects.
>
> Actually I th
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> I made it reject all but latin letters, which is the same restriction
>>> that's in place for timezone set filenames. That might be overly
>>> strong, but we definitely
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I made it reject all but latin letters, which is the same restriction
>> that's in place for timezone set filenames. That might be overly
>> strong, but we definitely have to forbid "." and "/" (and "\" on
>> Win
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
>> postgres=# CREATE TEXT SEARCH DICTIONARY ru_ispell (
>> TEMPLATE = ispell,
>> DictFile = 'russian-utf8.dict',
>> AffFile = 'russian-utf8.aff',
>> StopWords = russian
>> );
>>
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> postgres=# CREATE TEXT SEARCH DICTIONARY ru_ispell (
> TEMPLATE = ispell,
> DictFile = 'russian-utf8.dict',
> AffFile = 'russian-utf8.aff',
> StopWords = russian
> );
> ERROR: invalid text search configuration file na
I just tried on CVS HEAD and seems something is broken
postgres=# CREATE TEXT SEARCH DICTIONARY ru_ispell (
TEMPLATE = ispell,
DictFile = russian-utf8.dict,
AffFile = russian-utf8.aff,
StopWords = russian
);
ERROR: syntax error at or near "-"
LINE 3: DictFile =
Hello
I am found small bug
postgres=# CREATE TEXT SEARCH DICTIONARY cz1(TEMPLATE = ispell,
DictFile= 'cs_czutf');
ERROR: invalid text search configuration file name "cs_czutf"
postgres=# CREATE TEXT SEARCH DICTIONARY cz1(TEMPLATE = ispell,
DictFile= 'csczutf8');
ERROR: invalid text search confi
31 matches
Mail list logo
