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(' '
Christoph Zwerschke c...@online.de 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
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 removed
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)
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
On Mon, Apr 26, 2010 at 1:29 AM, manohar cr manohar...@gmail.com 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
Stefan Kirchev stefan.kirc...@gmail.com 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
Stefan Kirchev stefan.kirc...@gmail.com 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
Christoph Zwerschke c...@online.de 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
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
Donald Fraser postg...@kiwi-fraser.net 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
Tom Lane t...@sss.pgh.pa.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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.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
I wrote:
Donald Fraser postg...@kiwi-fraser.net 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
Tom Lane t...@sss.pgh.pa.us 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
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
17 matches
Mail list logo