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

Re: Bug with Tsearch and tsvector

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Donald Fraser" <postgres(at)kiwi-fraser(dot)net>, "[BUGS]" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Bug with Tsearch and tsvector
Date: 2010-04-26 18:43:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> ie the critical point seems to be that url_path is willing to soak
>> up a string containing "<" and ">", so the span tags don't get
>> recognized as separate lexemes.  While that's "obviously" the
>> wrong thing in this particular example, I'm not sure if it's the
>> wrong thing in general. Can anyone comment on the frequency of
>> usage of those two symbols in URLs?
> section 2.4.3 "delims" expressly
> forbids their use in URIs.
> In spite of the above prohibition, I notice that firefox and wget
> both seem to *try* to use such characters if they're included.

Hmm, thanks for the reference, but I'm not sure this is specifying
quite what we want to get at.  In particular I note that it excludes
'%' on the grounds that that ought to be escaped, so I guess this is
specifying the characters allowed in an underlying URI, *not* the
textual representation of a URI.

Still, it seems like this is a sufficient defense against any complaints
we might get for not treating "<" or ">" as part of a URL.

I wonder whether we ought to reject any of the other characters listed
here too.  Right now, the InURLPath state seems to eat everything until
a space, quote, or double quote mark.  We could easily make it stop at
"<" or ">" too, but what else?

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2010-04-26 19:23:53
Subject: Re: Bug with Tsearch and tsvector
Previous:From: Kevin GrittnerDate: 2010-04-26 18:19:52
Subject: Re: Bug with Tsearch and tsvector

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