"Kevin Grittner" writes:
> Hmm. Having typed that, I'm staring at the # character, which is
> used to mark off an anchor within an HTML page identified by the
> URL. Should we consider the # and anchor part of a URL?
Yeah, I would think so.
This discussion is making me think that my previous p
Tom Lane wrote:
> there's a potential compatibility issue here, so my thought is to
> apply this only in HEAD.
Agreed.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Tom Lane wrote:
> 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
I wrote:
> "Donald Fraser" writes:
>> Using the default tsearch configuration, for 'english', text is being
>> wrongly parsed into the tsvector type.
> ts_debug shows that it's being parsed like this:
> alias | description | token
>
"Kevin Grittner" writes:
> Tom Lane 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 su
Tom Lane 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 i
"Donald Fraser" writes:
> Using the default tsearch configuration, for 'english', text is being wrongly
> parsed into the tsvector type.
ts_debug shows that it's being parsed like this:
alias | description | token
| dictionaries
PostgreSQL 8.3.10 (on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2
20080704 (Red Hat 4.1.2-46))
OS: Linux Redhat EL 5.4
Database encoding: LATIN9
Using the default tsearch configuration, for 'english', text is being wrongly
parsed into the tsvector type.
The fail condition is shown w
Christoph Zwerschke wrote:
> Am 26.04.2010 12:11, schrieb Takahiro Itagaki:
>> Do you know how the SQL standard mention the behavior? IMHO,
>> postgres' behavior is more reasonable because
>> length(' '::char(1)) is 0.
>
> Just found http://troels.arvin.dk/db/rdbms/ which claims that this
> is
"Stefan Kirchev" writes:
> Bug reference: 5439
> Logged by: Stefan Kirchev
> Email address: stefan.kirc...@gmail.com
> PostgreSQL version: 8.3.3
> Operating system: Linux
> Description:Table crash after CLUSTER command
> Details:
> Hello,
> I order to keep good perfo
"Stefan Kirchev" wrote:
> PostgreSQL version: 8.3.3
> Description:Table crash after CLUSTER command
> I order to keep good performance on tables CLUSTER is done
> regularly on each table every Sunday. Almost every time we loose a
> table which must be recreated afterward. The error y
On Mon, Apr 26, 2010 at 1:29 AM, manohar cr wrote:
> Hi Kevin,
> Sorry for reply so late.
>
> Here is more detail for you.
>
> I am trying to install pgadmin3 in my suse linux enterprise server 10 with
> SP3.
> I am trying to install pgadmin3-1.10.2 version. I downloaded this version
> from inter
The following bug has been logged online:
Bug reference: 5439
Logged by: Stefan Kirchev
Email address: stefan.kirc...@gmail.com
PostgreSQL version: 8.3.3
Operating system: Linux
Description:Table crash after CLUSTER command
Details:
Hello,
I order to keep good perfo
Hi Kevin,
Sorry for reply so late.
Here is more detail for you.
I am trying to install pgadmin3 in my suse linux enterprise server 10 with
SP3.
I am trying to install pgadmin3-1.10.2 version. I downloaded this version
from internet.(it is mentioned that it supports for Open suse and suse
linux)
I
Am 26.04.2010 12:11, schrieb Takahiro Itagaki:
> The problem is not in ascii(), but in casting from char to text.
> We have only one version of ascii() in default; ascii(text).
> So, if you use ascii( ' '::char(1) ), it is actually handled as
> ascii( ' '::char(1)::text ). Traling spaces were remov
"Christoph Zwerschke" wrote:
>ascii(cast(' ' as char(1))),
>ascii(cast(' ' as char))
> both give 0.
>
> I think this quirk should be fixed or at least mentioned in the
> documentation of ascii().
The problem is not in ascii(), but in casting from char to text.
We have only one version
The following bug has been logged online:
Bug reference: 5438
Logged by: Christoph Zwerschke
Email address: c...@online.de
PostgreSQL version: 8.0-8.4
Operating system: all
Description:Bug/quirk in ascii() function
Details:
As you would expect,
ascii(cast(' ' as
17 matches
Mail list logo
