Skip site navigation (1) Skip section navigation (2)

Re: Bug with Tsearch and tsvector

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Donald Fraser" <postgres(at)kiwi-fraser(dot)net>, "[BUGS]" <pgsql-bugs(at)postgresql(dot)org>, "Oleg Bartunov" <oleg(at)sai(dot)msu(dot)su>, "Teodor Sigaev" <teodor(at)sigaev(dot)ru>
Subject: Re: Bug with Tsearch and tsvector
Date: 2010-04-27 14:42:12
Message-ID: 4BD6B1740200002500030E64@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-bugs
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> We'd probably not want to apply this as-is, but should first
>>> tighten up what characters URLPath allows, per Kevin's spec
>>> research.
>  
>> If we're headed that way, I figured I should double-check.  The
>> RFC I referenced was later obsoleted by:
>> http://www.ietf.org/rfc/rfc3986.txt
> 
> On reflection, since we're changing the behavior anyway, it seems
> like the most defensible thing to do is make the TS parser follow
> the RFC's allowed character set exactly.  The newer RFC doesn't
> restrict '#' so that possible corner case is gone.
 
It seems worth mentioning that there is a BSD licensed URI parser on
sourceforge:
 
http://uriparser.sourceforge.net/
 
I'm not advocating for using it, I just ran across it and it seemed
of possible interest.
 
-Kevin

In response to

pgsql-bugs by date

Next:From: Kevin GrittnerDate: 2010-04-27 15:42:37
Subject: Re: Bug with Tsearch and tsvector
Previous:From: Tom LaneDate: 2010-04-27 14:32:12
Subject: Re: Bug with Tsearch and tsvector

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group