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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2010-04-27 15:42:37 Re: Bug with Tsearch and tsvector
Previous Message Tom Lane 2010-04-27 14:32:12 Re: Bug with Tsearch and tsvector